suse-sles-15-sp4-byos-v20260124-x86_64 CVE scan on 2026-01-24T05:20:19+00:00

CVE-2022-43945 Severity: Important CVSS3 score: 8.8

Description: The Linux kernel NFSD implementation prior to versions 5.19.17 and 6.0.2 are vulnerable to buffer overflow. NFSD tracks the number of pages held by each NFSD thread by combining the receive and send buffers of a remote procedure call (RPC) into a single array of pages. A client can force the send buffer to shrink by sending an RPC message over TCP with garbage data added at the end of the message. The RPC message with garbage data is still correctly formed according to the specification and is passed forward to handlers. Vulnerable code in NFSD is not expecting the oversized request and writes beyond the allocated buffer space. CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-6174 Severity: Important CVSS3 score: 8.8

Description: When a non-x86 platform is detected, cloud-init grants root access to a hardcoded url with a local IP address. To prevent this, cloud-init default configurations disable platform enumeration.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).

CVE-2025-9187 Severity: Important CVSS3 score: 8.8

Description: Memory safety bugs present in Firefox 141 and Thunderbird 141. Some of these bugs showed evidence of memory corruption and we presume that with enough effort some of these could have been exploited to run arbitrary code. This vulnerability affects Firefox < 142 and Thunderbird < 142.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
mozilla-nss-certs < 3.112.2-150400.3.60.1 (version in image is 3.112-150400.3.57.1).

CVE-2025-40778 Severity: Important CVSS3 score: 8.6

Description: Under certain circumstances, BIND is too lenient when accepting records from answers, allowing an attacker to inject forged data into the cache.This issue affects BIND 9 versions 9.11.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.11.3-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
bind-utils < 9.16.50-150400.5.56.1 (version in image is 9.16.50-150400.5.49.1).

CVE-2025-40780 Severity: Important CVSS3 score: 8.6

Description: In specific circumstances, due to a weakness in the Pseudo Random Number Generator (PRNG) that is used, it is possible for an attacker to predict the source port and query ID that BIND will use.This issue affects BIND 9 versions 9.16.0 through 9.16.50, 9.18.0 through 9.18.39, 9.20.0 through 9.20.13, 9.21.0 through 9.21.12, 9.16.8-S1 through 9.16.50-S1, 9.18.11-S1 through 9.18.39-S1, and 9.20.9-S1 through 9.20.13-S1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
bind-utils < 9.16.50-150400.5.56.1 (version in image is 9.16.50-150400.5.49.1).

CVE-2025-68973 Severity: Important CVSS3 score: 8.0

Description: In GnuPG before 2.4.9, armor_filter in g10/armor.c has two increments of an index variable where one is intended, leading to an out-of-bounds write for crafted input. (For ExtendedLTS, 2.2.51 and later are fixed versions.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).

CVE-2022-50490 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Propagate error from htab_lock_bucket() to userspaceIn __htab_map_lookup_and_delete_batch() if htab_lock_bucket() returns-EBUSY, it will go to next bucket. Going to next bucket may not onlyskip the elements in current bucket silently, but also incurout-of-bound memory access or expose kernel memory to userspace ifcurrent bucket_cnt is greater than bucket_size or zero.Fixing it by stopping batch operation and returning -EBUSY whenhtab_lock_bucket() fails, and the application can retry or skip the busybatch as needed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50499 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-core: Fix double free in dvb_register_device()In function dvb_register_device() -> dvb_register_media_device() ->dvb_create_media_entity(), dvb->entity is allocated and initialized. Ifthe initialization fails, it frees the dvb->entity, and return an errorcode. The caller takes the error code and handles the error by callingdvb_media_device_free(), which unregisters the entity and frees thefield again if it is not NULL. As dvb->entity may not NULLed indvb_create_media_entity() when the allocation of dvbdev->pad fails, adouble free may occur. This may also cause an Use After free inmedia_device_unregister_entity().Fix this by storing NULL to dvb->entity when it is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50700 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Delay the unmapping of the bufferOn WCN3990, we are seeing a rare scenario where copy engine hardware issending a copy complete interrupt to the host driver while stillprocessing the buffer that the driver has sent, this is leading into anSMMU fault triggering kernel panic. This is happening on copy enginechannel 3 (CE3) where the driver normally enqueues WMI commands to thefirmware. Upon receiving a copy complete interrupt, host driver willimmediately unmap and frees the buffer presuming that hardware hasprocessed the buffer. In the issue case, upon receiving copy completeinterrupt, host driver will unmap and free the buffer but since hardwareis still accessing the buffer (which in this case got unmapped inparallel), SMMU hardware will trigger an SMMU fault resulting in akernel panic.In order to avoid this, as a work around, add a delay before unmappingthe copy engine source DMA buffer. This is conditionally done forWCN3990 and only for the CE3 channel where issue is seen.Below is the crash signature:wifi smmu error: kernel: [ 10.120965] arm-smmu 15000000.iommu: Unhandledcontext fault: fsr=0x402, iova=0x7fdfd8ac0,fsynr=0x500003,cbfrsynra=0xc1, cb=6 arm-smmu 15000000.iommu: Unhandledcontext fault:fsr=0x402, iova=0x7fe06fdc0, fsynr=0x710003,cbfrsynra=0xc1, cb=6 qcom-q6v5-mss 4080000.remoteproc: fatal errorreceived: err_qdi.c:1040:EF:wlan_process:0x1:WLAN RT:0x2091:cmnos_thread.c:3998:Asserted in copy_engine.c:AXI_ERROR_DETECTED:2149remoteproc remoteproc0: crash detected in4080000.remoteproc: type fatal error <3> remoteproc remoteproc0:handling crash #1 in 4080000.remoteprocpc : __arm_lpae_unmap+0x500/0x514lr : __arm_lpae_unmap+0x4bc/0x514sp : ffffffc011ffb530x29: ffffffc011ffb590 x28: 0000000000000000x27: 0000000000000000 x26: 0000000000000004x25: 0000000000000003 x24: ffffffc011ffb890x23: ffffffa762ef9be0 x22: ffffffa77244ef00x21: 0000000000000009 x20: 00000007fff7c000x19: 0000000000000003 x18: 0000000000000000x17: 0000000000000004 x16: ffffffd7a357d9f0x15: 0000000000000000 x14: 00fd5d4fa7ffffffx13: 000000000000000e x12: 0000000000000000x11: 00000000ffffffff x10: 00000000fffffe00x9 : 000000000000017c x8 : 000000000000000cx7 : 0000000000000000 x6 : ffffffa762ef9000x5 : 0000000000000003 x4 : 0000000000000004x3 : 0000000000001000 x2 : 00000007fff7c000x1 : ffffffc011ffb890 x0 : 0000000000000000 Call trace:__arm_lpae_unmap+0x500/0x514__arm_lpae_unmap+0x4bc/0x514__arm_lpae_unmap+0x4bc/0x514arm_lpae_unmap_pages+0x78/0xa4arm_smmu_unmap_pages+0x78/0x104__iommu_unmap+0xc8/0x1e4iommu_unmap_fast+0x38/0x48__iommu_dma_unmap+0x84/0x104iommu_dma_free+0x34/0x50dma_free_attrs+0xa4/0xd0ath10k_htt_rx_free+0xc4/0xf4 [ath10k_core] ath10k_core_stop+0x64/0x7c[ath10k_core]ath10k_halt+0x11c/0x180 [ath10k_core]ath10k_stop+0x54/0x94 [ath10k_core]drv_stop+0x48/0x1c8 [mac80211]ieee80211_do_open+0x638/0x77c [mac80211] ieee80211_open+0x48/0x5c[mac80211]__dev_open+0xb4/0x174__dev_change_flags+0xc4/0x1dcdev_change_flags+0x3c/0x7cdevinet_ioctl+0x2b4/0x580inet_ioctl+0xb0/0x1b4sock_do_ioctl+0x4c/0x16ccompat_ifreq_ioctl+0x1cc/0x35ccompat_sock_ioctl+0x110/0x2ac__arm64_compat_sys_ioctl+0xf4/0x3e0el0_svc_common+0xb4/0x17cel0_svc_compat_handler+0x2c/0x58el0_svc_compat+0x8/0x2cTested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50746 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: validate the extent length for uncompressed pclusterssyzkaller reported a KASAN use-after-free:https://syzkaller.appspot.com/bug?extid=2ae90e873e97f1faf6f2The referenced fuzzed image actually has two issues: - m_pa == 0 as a non-inlined pcluster; - The logical length is longer than its physical length.The first issue has already been addressed. This patch addressesthe second issue by checking the extent length validity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-4750 Severity: Important CVSS3 score: 7.8

Description: Use After Free in GitHub repository vim/vim prior to 9.0.1857.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-53676 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix buffer overflow in lio_target_nacl_info_show()The function lio_target_nacl_info_show() uses sprintf() in a loop to printdetails for every iSCSI connection in a session without checking for thebuffer length. With enough iSCSI connections it's possible to overflow thebuffer provided by configfs and corrupt the memory.This patch replaces sprintf() with sysfs_emit_at() that checks for bufferboundries.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53722 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:md: raid1: fix potential OOB in raid1_remove_disk()If rddev->raid_disk is greater than mddev->raid_disks, there will bean out-of-bounds in raid1_remove_disk(). We have already foundsimilar reports as follows:1) commit d17f744e883b ("md-raid10: fix KASAN warning")2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")Fix this bug by checking whether the "number" variable isvalid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-31133 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7 and below, 1.3.0-rc.1 through 1.3.1, 1.4.0-rc.1 and 1.4.0-rc.2 files, runc would not perform sufficient verification that the source of the bind-mount (i.e., the container's /dev/null) was actually a real /dev/null inode when using the container's /dev/null to mask. This exposes two methods of attack: an arbitrary mount gadget, leading to host information disclosure, host denial of service, container escape, or a bypassing of maskedPaths. This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).

CVE-2025-39978 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix potential use after free in otx2_tc_add_flow()This code calls kfree_rcu(new_node, rcu) and then dereferences "new_node"and then dereferences it on the next line. Two lines later, we takea mutex so I don't think this is an RCU safe region. Re-order it to dothe dereferences before queuing up the free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40139 Severity: Important CVSS3 score: 7.8

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in in smc_clc_prfx_set().smc_clc_prfx_set() is called during connect() and not under RCUnor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dev_dst_rcu() under rcu_read_lock()after kernel_getsockname().Note that the returned value of smc_clc_prfx_set() is not usedin the caller.While at it, we change the 1st arg of smc_clc_prfx_set[46]_rcu()not to touch dst there.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-45582 Severity: Important CVSS3 score: 7.8

Description: GNU Tar through 1.35 allows file overwrite via directory traversal in crafted TAR archives, with a certain two-step process. First, the victim must extract an archive that contains a ../ symlink to a critical directory. Second, the victim must extract an archive that contains a critical file, specified via a relative pathname that begins with the symlink name and ends with that critical file's name. Here, the extraction follows the symlink and overwrites the critical file. This bypasses the protection mechanism of "Member name contains '..'" that would occur for a single TAR archive that attempted to specify the critical file via a ../ approach. For example, the first archive can contain "x -> ../../../../../home/victim/.ssh" and the second archive can contain x/authorized_keys. This can affect server applications that automatically extract any number of user-supplied TAR archives, and were relying on the blocking of traversal. This can also affect software installation processes in which "tar xf" is run more than once (e.g., when installing a package can automatically install two dependencies that are set up as untrusted tarballs instead of official packages). NOTE: the official GNU Tar manual has an otherwise-empty directory for each "tar xf" in its Security Rules of Thumb; however, third-party advice leads users to run "tar xf" more than once into the same directory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
tar > 0-0 (version in image is 1.34-150000.3.34.1).

CVE-2025-52565 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. Versions 1.0.0-rc3 through 1.2.7, 1.3.0-rc.1 through 1.3.2, and 1.4.0-rc.1 through 1.4.0-rc.2, due to insufficient checks when bind-mounting `/dev/pts/$n` to `/dev/console` inside the container, an attacker can trick runc into bind-mounting paths which would normally be made read-only or be masked onto a path that the attacker can write to. This attack is very similar in concept and application to CVE-2025-31133, except that it attacks a similar vulnerability in a different target (namely, the bind-mount of `/dev/pts/$n` to `/dev/console` as configured for all containers that allocate a console). This happens after `pivot_root(2)`, so this cannot be used to write to host files directly -- however, as with CVE-2025-31133, this can load to denial of service of the host or a container breakout by providing the attacker with a writable copy of `/proc/sysrq-trigger` or `/proc/sys/kernel/core_pattern` (respectively). This issue is fixed in versions 1.2.8, 1.3.3 and 1.4.0-rc.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).

CVE-2025-52881 Severity: Important CVSS3 score: 7.8

Description: runc is a CLI tool for spawning and running containers according to the OCI specification. In versions 1.2.7, 1.3.2 and 1.4.0-rc.2, an attacker can trick runc into misdirecting writes to /proc to other procfs files through the use of a racing container with shared mounts (we have also verified this attack is possible to exploit using a standard Dockerfile with docker buildx build as that also permits triggering parallel execution of containers with custom shared mounts configured). This redirect could be through symbolic links in a tmpfs or theoretically other methods such as regular bind-mounts. While similar, the mitigation applied for the related CVE, CVE-2019-19921, was fairly limited and effectively only caused runc to verify that when LSM labels are written they are actually procfs files. This issue is fixed in versions 1.2.8, 1.3.3, and 1.4.0-rc.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
runc < 1.3.3-150000.85.1 (version in image is 1.2.6-150000.73.2).

CVE-2025-56005 Severity: Important CVSS3 score: 7.8

Description: An undocumented and unsafe feature in the PLY (Python Lex-Yacc) library 3.11 allows Remote Code Execution (RCE) via the `picklefile` parameter in the `yacc()` function. This parameter accepts a `.pkl` file that is deserialized with `pickle.load()` without validation. Because `pickle` allows execution of embedded code via `__reduce__()`, an attacker can achieve code execution by passing a malicious pickle file. The parameter is not mentioned in official documentation or the GitHub repository, yet it is active in the PyPI version. This introduces a stealthy backdoor and persistence risk.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-ply > 0-0 (version in image is 3.11-150400.12.6.1).

CVE-2025-62348 Severity: Important CVSS3 score: 7.8

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-salt < 3006.0-150400.8.91.1 (version in image is 3006.0-150400.8.83.6).

CVE-2026-0861 Severity: Important CVSS3 score: 7.8

Description: Passing too large an alignment to the memalign suite of functions (memalign, posix_memalign, aligned_alloc) in the GNU C Library version 2.30 to 2.42 may result in an integer overflow, which could consequently result in a heap corruption.Note that the attacker must have control over both, the size as well as the alignment arguments of the memalign function to be able to exploit this. The size parameter must be close enough to PTRDIFF_MAX so as to overflow size_t along with the large alignment argument. This limits the malicious inputs for the alignment for memalign to the range [1<<62+ 1, 1<<63] and exactly 1<<63 for posix_memalign and aligned_alloc.Typically the alignment argument passed to such functions is a known constrained quantity (e.g. page size, block size, struct sizes) and is not attacker controlled, because of which this may not be easily exploitable in practice. An application bug could potentially result in the input alignment being too large, e.g. due to a different buffer overflow or integer overflow in the application or its dependent libraries, but that is again an uncommon usage pattern given typical sources of alignments.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc > 0-0 (version in image is 2.31-150300.95.1).

CVE-2024-22232 Severity: Important CVSS3 score: 7.7

Description: A specially crafted url can be created which leads to a directory traversal in the salt file server.A malicious user can read an arbitrary file from a Salt master's filesystem.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
python3-salt > 0-0 (version in image is 3006.0-150400.8.83.6).

CVE-2025-13601 Severity: Important CVSS3 score: 7.7

Description: A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the g_escape_uri_string() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.1).

CVE-2019-19603 Severity: Important CVSS3 score: 7.5

Description: SQLite 3.30.1 mishandles certain SELECT statements with a nonexistent VIEW, leading to an application crash.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2019-19926 Severity: Important CVSS3 score: 7.5

Description: multiSelect in select.c in SQLite 3.30.1 mishandles certain errors during parsing, as demonstrated by errors from sqlite3WindowRewrite() calls. NOTE: this vulnerability exists because of an incomplete fix for CVE-2019-19880.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2023-38039 Severity: Important CVSS3 score: 7.5

Description: When curl retrieves an HTTP response, it stores the incoming headers so thatthey can be accessed later via the libcurl headers API.However, curl did not have a limit in how many or how large headers it wouldaccept in a response, allowing a malicious server to stream an endless seriesof headers and eventually cause curl to run out of heap memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2024-23334 Severity: Important CVSS3 score: 7.5

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. When using aiohttp as a web server and configuring static routes, it is necessary to specify the root path for static files. Additionally, the option 'follow_symlinks' can be used to determine whether to follow symbolic links outside the static root directory. When 'follow_symlinks' is set to True, there is no validation to check if reading a file is within the root directory. This can lead to directory traversal vulnerabilities, resulting in unauthorized access to arbitrary files on the system, even when symlinks are not present. Disabling follow_symlinks and using a reverse proxy are encouraged mitigations. Version 3.9.2 fixes this issue.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2024-25062 Severity: Important CVSS3 score: 7.5

Description: An issue was discovered in libxml2 before 2.11.7 and 2.12.x before 2.12.5. When using the XML Reader interface with DTD validation and XInclude expansion enabled, processing crafted XML documents can lead to an xmlValidatePopElement use-after-free.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2025-11468 Severity: Important CVSS3 score: 7.5

Description: When folding a long comment in an email header containing exclusively unfoldable characters, the parenthesis would not be preserved. This could be used for injecting headers into email messages where addresses are user-controlled and not sanitized.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-11731 Severity: Important CVSS3 score: 7.5

Description: A flaw was found in the exsltFuncResultComp() function of libxslt, which handles EXSLT elements during stylesheet parsing. Due to improper type handling, the function may treat an XML document node as a regular XML element node, resulting in a type confusion. This can cause unexpected memory reads and potential crashes. While difficult to exploit, the flaw could lead to application instability or denial of service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxslt1 > 0-0 (version in image is 1.1.34-150400.3.6.1).

CVE-2025-27144 Severity: Important CVSS3 score: 7.5

Description: Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. In versions on the 4.x branch prior to version 4.0.5, when parsing compact JWS or JWE input, Go JOSE could use excessive memory. The code used strings.Split(token, ".") to split JWT tokens, which is vulnerable to excessive memory consumption when processing maliciously crafted tokens with a large number of `.` characters. An attacker could exploit this by sending numerous malformed tokens, leading to memory exhaustion and a Denial of Service. Version 4.0.5 fixes this issue. As a workaround, applications could pre-validate that payloads passed to Go JOSE do not contain an excessive number of `.` characters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.27-150000.123.1).

CVE-2025-30204 Severity: Important CVSS3 score: 7.5

Description: golang-jwt is a Go implementation of JSON Web Tokens. Starting in version 3.2.0 and prior to versions 5.2.2 and 4.5.2, the function parse.ParseUnverified splits (via a call to strings.Split) its argument (which is untrusted data) on periods. As a result, in the face of a malicious request whose Authorization header consists of Bearer followed by many period characters, a call to that function incurs allocations to the tune of O(n) bytes (where n stands for the length of the function's argument), with a constant factor of about 16. This issue is fixed in 5.2.2 and 4.5.2.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-40204 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-47913 Severity: Important CVSS3 score: 7.5

Description: SSH clients receiving SSH_AGENT_SUCCESS when expecting a typed response will panic and cause early termination of the client process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-68813 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix ipv4 null-ptr-deref in route error pathThe IPv4 code path in __ip_vs_get_out_rt() calls dst_link_failure()without ensuring skb->dev is set, leading to a NULL pointer dereferencein fib_compute_spec_dst() when ipv4_link_failure() attempts to sendICMP destination unreachable messages.The issue emerged after commit ed0de45a1008 ("ipv4: recompile ip optionsin ipv4_link_failure") started calling __ip_options_compile() fromipv4_link_failure(). This code path eventually calls fib_compute_spec_dst()which dereferences skb->dev. An attempt was made to fix the NULL skb->devdereference in commit 0113d9c9d1cc ("ipv4: fix null-deref inipv4_link_failure"), but it only addressed the immediate dev_net(skb->dev)dereference by using a fallback device. The fix was incomplete becausefib_compute_spec_dst() later in the call chain still accesses skb->devdirectly, which remains NULL when IPVS calls dst_link_failure().The crash occurs when:1. IPVS processes a packet in NAT mode with a misconfigured destination2. Route lookup fails in __ip_vs_get_out_rt() before establishing a route3. The error path calls dst_link_failure(skb) with skb->dev == NULL4. ipv4_link_failure() -> ipv4_send_dest_unreach() -> __ip_options_compile() -> fib_compute_spec_dst()5. fib_compute_spec_dst() dereferences NULL skb->devApply the same fix used for IPv6 in commit 326bf17ea5d4 ("ipvs: fixipv6 route unreach panic"): set skb->dev from skb_dst(skb)->dev beforecalling dst_link_failure().KASAN: null-ptr-deref in range [0x0000000000000328-0x000000000000032f]CPU: 1 PID: 12732 Comm: syz.1.3469 Not tainted 6.6.114 #2RIP: 0010:__in_dev_get_rcu include/linux/inetdevice.h:233RIP: 0010:fib_compute_spec_dst+0x17a/0x9f0 net/ipv4/fib_frontend.c:285Call Trace: spec_dst_fill net/ipv4/ip_options.c:232 spec_dst_fill net/ipv4/ip_options.c:229 __ip_options_compile+0x13a1/0x17d0 net/ipv4/ip_options.c:330 ipv4_send_dest_unreach net/ipv4/route.c:1252 ipv4_link_failure+0x702/0xb80 net/ipv4/route.c:1265 dst_link_failure include/net/dst.h:437 __ip_vs_get_out_rt+0x15fd/0x19e0 net/netfilter/ipvs/ip_vs_xmit.c:412 ip_vs_nat_xmit+0x1d8/0xc80 net/netfilter/ipvs/ip_vs_xmit.c:764

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-69223 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-69227 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow for an infinite loop to occur when assert statements are bypassed, resulting in a DoS attack when processing a POST body. If optimizations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-69228 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a request to be crafted in such a way that an AIOHTTP server's memory fills up uncontrollably during processing. If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-69229 Severity: Important CVSS3 score: 7.5

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. In versions 3.13.2 and below, handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. If an application makes use of the request.read() method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-71085 Severity: Important CVSS3 score: 7.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: BUG() in pskb_expand_head() as part of calipso_skbuff_setattr()There exists a kernel oops caused by a BUG_ON(nhead < 0) atnet/core/skbuff.c:2232 in pskb_expand_head().This bug is triggered as part of the calipso_skbuff_setattr()routine when skb_cow() is passed headroom > INT_MAX(i.e. (int)(skb_headroom(skb) + len_delta) < 0).The root cause of the bug is due to an implicit integer cast in__skb_cow(). The check (headroom > skb_headroom(skb)) is meant to ensurethat delta = headroom - skb_headroom(skb) is never negative, otherwisewe will trigger a BUG_ON in pskb_expand_head(). However, ifheadroom > INT_MAX and delta <= -NET_SKB_PAD, the check passes, deltabecomes negative, and pskb_expand_head() is passed a negative value fornhead.Fix the trigger condition in calipso_skbuff_setattr(). Avoid passing"negative" headroom sizes to skb_cow() within calipso_skbuff_setattr()by only using skb_cow() to grow headroom.PoC: Using `netlabelctl` tool: netlabelctl map del default netlabelctl calipso add pass doi:7 netlabelctl map add default address:0::1/128 protocol:calipso,7 Then run the following PoC: int fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); // setup msghdr int cmsg_size = 2; int cmsg_len = 0x60; struct msghdr msg; struct sockaddr_in6 dest_addr; struct cmsghdr * cmsg = (struct cmsghdr *) calloc(1, sizeof(struct cmsghdr) + cmsg_len); msg.msg_name = &dest_addr; msg.msg_namelen = sizeof(dest_addr); msg.msg_iov = NULL; msg.msg_iovlen = 0; msg.msg_control = cmsg; msg.msg_controllen = cmsg_len; msg.msg_flags = 0; // setup sockaddr dest_addr.sin6_family = AF_INET6; dest_addr.sin6_port = htons(31337); dest_addr.sin6_flowinfo = htonl(31337); dest_addr.sin6_addr = in6addr_loopback; dest_addr.sin6_scope_id = 31337; // setup cmsghdr cmsg->cmsg_len = cmsg_len; cmsg->cmsg_level = IPPROTO_IPV6; cmsg->cmsg_type = IPV6_HOPOPTS; char * hop_hdr = (char *)cmsg + sizeof(struct cmsghdr); hop_hdr[1] = 0x9; //set hop size - (0x9 + 1) * 8 = 80 sendmsg(fd, &msg, 0);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71120 Severity: Important CVSS3 score: 7.5

Description: 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_verfA zero length gss_token results in pages == 0 and in_token->pages[0]is NULL. The code unconditionally evaluatespage_address(in_token->pages[0]) for the initial memcpy, which candereference NULL even when the copy length is 0. Guard the firstmemcpy so it only runs when length > 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2026-0672 Severity: Important CVSS3 score: 7.5

Description: When using http.cookies.Morsel, user-controlled cookie values and parameters can allow injecting HTTP headers into messages. Patch rejects all control characters within cookie names, values, and parameters.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2026-23490 Severity: Important CVSS3 score: 7.5

Description: pyasn1 is a generic ASN.1 library for Python. Prior to 0.6.2, a Denial-of-Service issue has been found that leads to memory exhaustion from malformed RELATIVE-OID with excessive continuation octets. This vulnerability is fixed in 0.6.2.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-pyasn1 > 0-0 (version in image is 0.5.0-150400.12.7.2).

CVE-2025-45768 Severity: Important CVSS3 score: 7.4

Description: pyjwt v2.10.1 was discovered to contain weak encryption. NOTE: this is disputed by the Supplier because the key length is chosen by the application that uses the library (admittedly, library users may benefit from a minimum value and a mechanism for opting in to strict enforcement).

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-PyJWT > 0-0 (version in image is 2.8.0-150400.8.7.2).

CVE-2024-25621 Severity: Important CVSS3 score: 7.3

Description: containerd is an open-source container runtime. Versions 0.1.0 through 1.7.28, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4 and 2.2.0-beta.0 through 2.2.0-rc.1 have an overly broad default permission vulnerability. Directory paths `/var/lib/containerd`, `/run/containerd/io.containerd.grpc.v1.cri` and `/run/containerd/io.containerd.sandbox.controller.v1.shim` were all created with incorrect permissions. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. Workarounds include updating system administrator permissions so the host can manually chmod the directories to not have group or world accessible permissions, or to run containerd in rootless mode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.128.1 (version in image is 1.7.27-150000.123.1).

CVE-2025-68284 Severity: Important CVSS3 score: 7.3

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: prevent potential out-of-bounds writes in handle_auth_session_key()The len field originates from untrusted network packets. Boundarychecks have been added to prevent potential out-of-bounds writes whendecrypting the connection secret or processing service tickets.[ idryomov: changelog ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2020-13435 Severity: Important CVSS3 score: 7.1

Description: SQLite through 3.32.0 has a segmentation fault in sqlite3ExprCodeTarget in expr.c.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2022-50487 Severity: Important CVSS3 score: 7.1

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-14087 Severity: Important CVSS3 score: 7.1

Description: A flaw was found in GLib (Gnome Lib). This vulnerability allows a remote attacker to cause heap corruption, leading to a denial of service or potential code execution via a buffer-underflow in the GVariant parser when processing maliciously crafted input strings.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.1).

CVE-2025-66293 Severity: Important CVSS3 score: 7.1

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to 1.6.52, an out-of-bounds read vulnerability in libpng's simplified API allows reading up to 1012 bytes beyond the png_sRGB_base[512] array when processing valid palette PNG images with partial transparency and gamma correction. The PNG files that trigger this vulnerability are valid per the PNG specification; the bug is in libpng's internal state management. Upgrade to libpng 1.6.52 or later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).

CVE-2022-50327 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor: idle: Check acpi_fetch_acpi_dev() return valueThe return value of acpi_fetch_acpi_dev() could be NULL, which wouldcause a NULL pointer dereference to occur in acpi_device_hid().[ rjw: Subject and changelog edits, added empty line after if () ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50334 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: fix null-ptr-deref in hugetlbfs_parse_param()Syzkaller reports a null-ptr-deref bug as follows:======================================================KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]RIP: 0010:hugetlbfs_parse_param+0x1dd/0x8e0 fs/hugetlbfs/inode.c:1380[...]Call Trace: vfs_parse_fs_param fs/fs_context.c:148 [inline] vfs_parse_fs_param+0x1f9/0x3c0 fs/fs_context.c:129 vfs_parse_fs_string+0xdb/0x170 fs/fs_context.c:191 generic_parse_monolithic+0x16f/0x1f0 fs/fs_context.c:231 do_new_mount fs/namespace.c:3036 [inline] path_mount+0x12de/0x1e20 fs/namespace.c:3370 do_mount fs/namespace.c:3383 [inline] __do_sys_mount fs/namespace.c:3591 [inline] __se_sys_mount fs/namespace.c:3568 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3568 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] ======================================================According to commit "vfs: parse: deal with zero length string value",kernel will set the param->string to null pointer in vfs_parse_fs_string()if fs string has zero length.Yet the problem is that, hugetlbfs_parse_param() will dereference theparam->string, without checking whether it is a null pointer. To be morespecific, if hugetlbfs_parse_param() parses an illegal mount parameter,such as "size=,", kernel will constructs struct fs_parameter with nullpointer in vfs_parse_fs_string(), then passes this struct fs_parameter tohugetlbfs_parse_param(), which triggers the above null-ptr-deref bug.This patch solves it by adding sanity check on param->stringin hugetlbfs_parse_param().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50488 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:block, bfq: fix possible uaf for 'bfqq->bic'Our test report a uaf for 'bfqq->bic' in 5.10:==================================================================BUG: KASAN: use-after-free in bfq_select_queue+0x378/0xa30CPU: 6 PID: 2318352 Comm: fsstress Kdump: loaded Not tainted 5.10.0-60.18.0.50.h602.kasan.eulerosv2r11.x86_64 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58-20220320_160524-szxrtosci10000 04/01/2014Call Trace: bfq_select_queue+0x378/0xa30 bfq_dispatch_request+0xe8/0x130 blk_mq_do_dispatch_sched+0x62/0xb0 __blk_mq_sched_dispatch_requests+0x215/0x2a0 blk_mq_sched_dispatch_requests+0x8f/0xd0 __blk_mq_run_hw_queue+0x98/0x180 __blk_mq_delay_run_hw_queue+0x22b/0x240 blk_mq_run_hw_queue+0xe3/0x190 blk_mq_sched_insert_requests+0x107/0x200 blk_mq_flush_plug_list+0x26e/0x3c0 blk_finish_plug+0x63/0x90 __iomap_dio_rw+0x7b5/0x910 iomap_dio_rw+0x36/0x80 ext4_dio_read_iter+0x146/0x190 [ext4] ext4_file_read_iter+0x1e2/0x230 [ext4] new_sync_read+0x29f/0x400 vfs_read+0x24e/0x2d0 ksys_read+0xd5/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Commit 3bc5e683c67d ("bfq: Split shared queues on move between cgroups")changes that move process to a new cgroup will allocate a new bfqq touse, however, the old bfqq and new bfqq can point to the same bic:1) Initial state, two process with io in the same cgroup.Process 1 Process 2 (BIC1) (BIC2) | ^ | ^ | | | | V | V | bfqq1 bfqq22) bfqq1 is merged to bfqq2.Process 1 Process 2 (BIC1) (BIC2) | | \-------------\| V bfqq1 bfqq2(coop)3) Process 1 exit, then issue new io(denoce IOA) from Process 2. (BIC2) | ^ | | V | bfqq2(coop)4) Before IOA is completed, move Process 2 to another cgroup and issue io.Process 2 (BIC2) ^ |\--------------\ | V bfqq2 bfqq3Now that BIC2 points to bfqq3, while bfqq2 and bfqq3 both point to BIC2.If all the requests are completed, and Process 2 exit, BIC2 will befreed while there is no guarantee that bfqq2 will be freed before BIC2.Fix the problem by clearing bfqq->bic while bfqq is detached from bic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50697 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:mrp: introduce active flags to prevent UAF when applicant uninitThe caller of del_timer_sync must prevent restarting of the timer, Ifwe have no this synchronization, there is a small probability that thecancellation will not be successful.And syzbot report the fellowing crash:==================================================================BUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]BUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605Write at addr f9ff000024df6058 by task syz-fuzzer/2256Pointer tag: [f9], memory tag: [fe]CPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-ge01d50cbd6ee #0Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156 dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline] show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x1a8/0x4a0 mm/kasan/report.c:395 kasan_report+0x94/0xb4 mm/kasan/report.c:495 __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320 do_bad_area arch/arm64/mm/fault.c:473 [inline] do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749 do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825 el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367 el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427 el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576 hlist_add_head include/linux/list.h:929 [inline] enqueue_timer+0x18/0xa4 kernel/time/timer.c:605 mod_timer+0x14/0x20 kernel/time/timer.c:1161 mrp_periodic_timer_arm net/802/mrp.c:614 [inline] mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627 call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474 expire_timers+0x98/0xc4 kernel/time/timer.c:1519To fix it, we can introduce a new active flags to make sure the timer willnot restart.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50721 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sgThe calling convention for pre_slave_sg is to return NULL on error andprovide an error log to the system. Qcom-adm instead provide errorpointer when an error occur. This indirectly cause kernel panic forexample for the nandc driver that checks only if the pointer returned bydevice_prep_slave_sg is not NULL. Returning an error pointer makes nandcthink the device_prep_slave_sg function correctly completed and makesthe kernel panics later in the code.While nandc is the one that makes the kernel crash, it was pointed outthat the real problem is qcom-adm not following calling convention forthat function.To fix this, drop returning error pointer and return NULL with an errorlog.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-42465 Severity: Important CVSS3 score: 7.0

Description: Sudo before 1.9.15 might allow row hammer attacks (for authentication bypass or privilege escalation) because application logic sometimes is based on not equaling an error value (instead of equaling a success value), and because the values do not resist flips of a single bit.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sudo > 0-0 (version in image is 1.9.9-150400.4.39.1).

CVE-2023-53254 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:cacheinfo: Fix shared_cpu_map to handle shared caches at different levelsThe cacheinfo sets up the shared_cpu_map by checking whether the cacheswith the same index are shared between CPUs. However, this will triggerslab-out-of-bounds access if the CPUs do not have the same cache hierarchy.Another problem is the mismatched shared_cpu_map when the shared cache doesnot have the same index between CPUs.CPU0 I D L3index 0 1 2 x ^ ^ ^ ^index 0 1 2 3CPU1 I D L2 L3This patch checks each cache is shared with all caches on other CPUs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53574 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: delete timer and free skb queue when unloadingFix possible crash and memory leak on driver unload by deletingTX purge timer and freeing C2H queue in 'rtw_core_deinit()',shrink critical section in the latter by freeing COEX queueout of TX report lock scope.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53608 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential UAF of struct nilfs_sc_info in nilfs_segctor_thread()The finalization of nilfs_segctor_thread() can race withnilfs_segctor_kill_thread() which terminates that thread, potentiallycausing a use-after-free BUG as KASAN detected.At the end of nilfs_segctor_thread(), it assigns NULL to "sc_task" memberof "struct nilfs_sc_info" to indicate the thread has finished, and thennotifies nilfs_segctor_kill_thread() of this using waitqueue"sc_wait_task" on the struct nilfs_sc_info.However, here, immediately after the NULL assignment to "sc_task", it ispossible that nilfs_segctor_kill_thread() will detect it and return tocontinue the deallocation, freeing the nilfs_sc_info structure before thethread does the notification.This fixes the issue by protecting the NULL assignment to "sc_task" andits notification, with spinlock "sc_state_lock" of the structnilfs_sc_info. Since nilfs_segctor_kill_thread() does a final check tosee if "sc_task" is NULL with "sc_state_lock" locked, this can eliminatethe race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53640 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: lpass: Fix for KASAN use_after_free out of boundsWhen we run syzkaller we get below Out of Bounds error."KASAN: slab-out-of-bounds Read in regcache_flat_read"Below is the backtrace of the issue:BUG: KASAN: slab-out-of-bounds in regcache_flat_read+0x10c/0x110Read of size 4 at addr ffffff8088fbf714 by task syz-executor.4/14144CPU: 6 PID: 14144 Comm: syz-executor.4 Tainted: G WHardware name: Qualcomm Technologies, Inc. sc7280 CRD platform (rev5+) (DT)Call trace:dump_backtrace+0x0/0x4ecshow_stack+0x34/0x50dump_stack_lvl+0xdc/0x11cprint_address_description+0x30/0x2d8kasan_report+0x178/0x1e4__asan_report_load4_noabort+0x44/0x50regcache_flat_read+0x10c/0x110regcache_read+0xf8/0x5a0_regmap_read+0x45c/0x86c_regmap_update_bits+0x128/0x290regmap_update_bits_base+0xc0/0x15csnd_soc_component_update_bits+0xa8/0x22csnd_soc_component_write_field+0x68/0xd4tx_macro_put_dec_enum+0x1d0/0x268snd_ctl_elem_write+0x288/0x474By Error checking and checking valid values issue gets rectifies.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53659 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix out-of-bounds when setting channels on removeIf we set channels greater during iavf_remove(), and waiting reset donewould be timeout, then returned with error but changed num_active_queuesdirectly, that will lead to OOB like the following logs. Because thenum_active_queues is greater than tx/rx_rings[] allocated actually.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 3506.152887] iavf 0000:41:02.0: Removing device[ 3510.400799] ==================================================================[ 3510.400820] BUG: KASAN: slab-out-of-bounds in iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400823] Read of size 8 at addr ffff88b6f9311008 by task repro.sh/55536[ 3510.400823][ 3510.400830] CPU: 101 PID: 55536 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 3510.400832] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 3510.400835] Call Trace:[ 3510.400851] dump_stack+0x71/0xab[ 3510.400860] print_address_description+0x6b/0x290[ 3510.400865] ? iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400868] kasan_report+0x14a/0x2b0[ 3510.400873] iavf_free_all_tx_resources+0x156/0x160 [iavf][ 3510.400880] iavf_remove+0x2b6/0xc70 [iavf][ 3510.400884] ? iavf_free_all_rx_resources+0x160/0x160 [iavf][ 3510.400891] ? wait_woken+0x1d0/0x1d0[ 3510.400895] ? notifier_call_chain+0xc1/0x130[ 3510.400903] pci_device_remove+0xa8/0x1f0[ 3510.400910] device_release_driver_internal+0x1c6/0x460[ 3510.400916] pci_stop_bus_device+0x101/0x150[ 3510.400919] pci_stop_and_remove_bus_device+0xe/0x20[ 3510.400924] pci_iov_remove_virtfn+0x187/0x420[ 3510.400927] ? pci_iov_add_virtfn+0xe10/0xe10[ 3510.400929] ? pci_get_subsys+0x90/0x90[ 3510.400932] sriov_disable+0xed/0x3e0[ 3510.400936] ? bus_find_device+0x12d/0x1a0[ 3510.400953] i40e_free_vfs+0x754/0x1210 [i40e][ 3510.400966] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 3510.400968] ? pci_get_device+0x7c/0x90[ 3510.400970] ? pci_get_subsys+0x90/0x90[ 3510.400982] ? pci_vfs_assigned.part.7+0x144/0x210[ 3510.400987] ? __mutex_lock_slowpath+0x10/0x10[ 3510.400996] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 3510.401001] sriov_numvfs_store+0x214/0x290[ 3510.401005] ? sriov_totalvfs_show+0x30/0x30[ 3510.401007] ? __mutex_lock_slowpath+0x10/0x10[ 3510.401011] ? __check_object_size+0x15a/0x350[ 3510.401018] kernfs_fop_write+0x280/0x3f0[ 3510.401022] vfs_write+0x145/0x440[ 3510.401025] ksys_write+0xab/0x160[ 3510.401028] ? __ia32_sys_read+0xb0/0xb0[ 3510.401031] ? fput_many+0x1a/0x120[ 3510.401032] ? filp_close+0xf0/0x130[ 3510.401038] do_syscall_64+0xa0/0x370[ 3510.401041] ? page_fault+0x8/0x30[ 3510.401043] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 3510.401073] RIP: 0033:0x7f3a9bb842c0[ 3510.401079] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53673 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: call disconnect callback before deleting connIn hci_cs_disconnect, we do hci_conn_del even if disconnection failed.ISO, L2CAP and SCO connections refer to the hci_conn withouthci_conn_get, so disconn_cfm must be called so they can clean up theirconn, otherwise use-after-free occurs.ISO:==========================================================iso_sock_connect:880: sk 00000000eabd6557iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da...iso_conn_add:140: hcon 000000001696f1fd conn 00000000b6251073hci_dev_put:1487: hci0 orig refcnt 17__iso_chan_add:214: conn 00000000b6251073iso_sock_clear_timer:117: sock 00000000eabd6557 state 3...hci_rx_work:4085: hci0 Event packethci_event_packet:7601: hci0: event 0x0fhci_cmd_status_evt:4346: hci0: opcode 0x0406hci_cs_disconnect:2760: hci0: status 0x0chci_sent_cmd_data:3107: hci0 opcode 0x0406hci_conn_del:1151: hci0 hcon 000000001696f1fd handle 2560hci_conn_unlink:1102: hci0: hcon 000000001696f1fdhci_conn_drop:1451: hcon 00000000d8521aaf orig refcnt 2hci_chan_list_flush:2780: hcon 000000001696f1fdhci_dev_put:1487: hci0 orig refcnt 21hci_dev_put:1487: hci0 orig refcnt 20hci_req_cmd_complete:3978: opcode 0x0406 status 0x0c... ...iso_sock_sendmsg:1098: sock 00000000dea5e2e0, sk 00000000eabd6557BUG: kernel NULL pointer dereference, address: 0000000000000668PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTIHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014RIP: 0010:iso_sock_sendmsg (net/bluetooth/iso.c:1112) bluetooth==========================================================L2CAP:==================================================================hci_cmd_status_evt:4359: hci0: opcode 0x0406hci_cs_disconnect:2760: hci0: status 0x0chci_sent_cmd_data:3085: hci0 opcode 0x0406hci_conn_del:1151: hci0 hcon ffff88800c999000 handle 3585hci_conn_unlink:1102: hci0: hcon ffff88800c999000hci_chan_list_flush:2780: hcon ffff88800c999000hci_chan_del:2761: hci0 hcon ffff88800c999000 chan ffff888018ddd280...BUG: KASAN: slab-use-after-free in hci_send_acl+0x2d/0x540 [bluetooth]Read of size 8 at addr ffff888018ddd298 by task bluetoothd/1175CPU: 0 PID: 1175 Comm: bluetoothd Tainted: G E 6.4.0-rc4+ #2Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-1.fc38 04/01/2014Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xf8/0x180 ? hci_send_acl+0x2d/0x540 [bluetooth] kasan_report+0xa8/0xe0 ? hci_send_acl+0x2d/0x540 [bluetooth] hci_send_acl+0x2d/0x540 [bluetooth] ? __pfx___lock_acquire+0x10/0x10 l2cap_chan_send+0x1fd/0x1300 [bluetooth] ? l2cap_sock_sendmsg+0xf2/0x170 [bluetooth] ? __pfx_l2cap_chan_send+0x10/0x10 [bluetooth] ? lock_release+0x1d5/0x3c0 ? mark_held_locks+0x1a/0x90 l2cap_sock_sendmsg+0x100/0x170 [bluetooth] sock_write_iter+0x275/0x280 ? __pfx_sock_write_iter+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 do_iter_readv_writev+0x176/0x220 ? __pfx_do_iter_readv_writev+0x10/0x10 ? find_held_lock+0x83/0xa0 ? selinux_file_permission+0x13e/0x210 do_iter_write+0xda/0x340 vfs_writev+0x1b4/0x400 ? __pfx_vfs_writev+0x10/0x10 ? __seccomp_filter+0x112/0x750 ? populate_seccomp_data+0x182/0x220 ? __fget_light+0xdf/0x100 ? do_writev+0x19d/0x210 do_writev+0x19d/0x210 ? __pfx_do_writev+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0x60/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 ? do_syscall_64+0x6c/0x90 ? lockdep_hardirqs_on_prepare+0x149/0x210 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7ff45cb23e64Code: 15 d1 1f 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 9d a7 0d 00 00 74 13 b8 14 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89RSP: 002b:00007fff21ae09b8 EFLAGS: 00000202 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53717 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()Fix a stack-out-of-bounds write that occurs in a WMI response callbackfunction that is called after a timeout occurs in ath9k_wmi_cmd().The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer thatcould no longer be valid when a timeout occurs. Set wmi->last_seq_id to0 when a timeout occurred.Found by a modified version of syzkaller.BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rxWrite of size 4Call Trace: memcpy ath9k_wmi_ctrl_rx ath9k_htc_rx_msg ath9k_hif_usb_reg_in_cb __usb_hcd_giveback_urb usb_hcd_giveback_urb dummy_timer call_timer_fn run_timer_softirq __do_softirq irq_exit_rcu sysvec_apic_timer_interrupt

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53781 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in tcp_write_timer_handler().With Eric's ref tracker, syzbot finally found a repro foruse-after-free in tcp_write_timer_handler() by kernel TCPsockets. [0]If SMC creates a kernel socket in __smc_create(), the kernelsocket is supposed to be freed in smc_clcsock_release() bycalling sock_release() when we close() the parent SMC socket.However, at the end of smc_clcsock_release(), the kernelsocket's sk_state might not be TCP_CLOSE. This means thatwe have not called inet_csk_destroy_sock() in __tcp_close()and have not stopped the TCP timers.The kernel socket's TCP timers can be fired later, so weneed to hold a refcnt for net as we do for MPTCP subflowsin mptcp_subflow_create_socket().[0]:leaked reference. sk_alloc (./include/net/net_namespace.h:335 net/core/sock.c:2108) inet_create (net/ipv4/af_inet.c:319 net/ipv4/af_inet.c:244) __sock_create (net/socket.c:1546) smc_create (net/smc/af_smc.c:3269 net/smc/af_smc.c:3284) __sock_create (net/socket.c:1546) __sys_socket (net/socket.c:1634 net/socket.c:1618 net/socket.c:1661) __x64_sys_socket (net/socket.c:1672) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)==================================================================BUG: KASAN: slab-use-after-free in tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594)Read of size 1 at addr ffff888052b65e0d by task syzrepro/18091CPU: 0 PID: 18091 Comm: syzrepro Tainted: G W 6.3.0-rc4-01174-gb5d54eb5899a #7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.amzn2022.0.1 04/01/2014Call Trace: dump_stack_lvl (lib/dump_stack.c:107) print_report (mm/kasan/report.c:320 mm/kasan/report.c:430) kasan_report (mm/kasan/report.c:538) tcp_write_timer_handler (net/ipv4/tcp_timer.c:378 net/ipv4/tcp_timer.c:624 net/ipv4/tcp_timer.c:594) tcp_write_timer (./include/linux/spinlock.h:390 net/ipv4/tcp_timer.c:643) call_timer_fn (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/timer.h:127 kernel/time/timer.c:1701) __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2022) run_timer_softirq (kernel/time/timer.c:2037) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:572) __irq_exit_rcu (kernel/softirq.c:445 kernel/softirq.c:650) irq_exit_rcu (kernel/softirq.c:664) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1107 (discriminator 14))

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54142 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Fix use-after-free in __gtp_encap_destroy().syzkaller reported use-after-free in __gtp_encap_destroy(). [0]It shows the same process freed sk and touched it illegally.Commit e198987e7dd7 ("gtp: fix suspicious RCU usage") added lock_sock()and release_sock() in __gtp_encap_destroy() to protect sk->sk_user_data,but release_sock() is called after sock_put() releases the last refcnt.[0]:BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]BUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]BUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]BUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline]BUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178Write of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401CPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:351 [inline] print_report+0xcc/0x620 mm/kasan/report.c:462 kasan_report+0xb2/0xe0 mm/kasan/report.c:572 check_region_inline mm/kasan/generic.c:181 [inline] kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline] queued_spin_lock include/asm-generic/qspinlock.h:111 [inline] do_raw_spin_lock include/linux/spinlock.h:186 [inline] __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline] _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:355 [inline] release_sock+0x1f/0x1a0 net/core/sock.c:3526 gtp_encap_disable_sock drivers/net/gtp.c:651 [inline] gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664 gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728 unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841 rtnl_delete_link net/core/rtnetlink.c:3216 [inline] rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268 rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423 netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b7/0x200 net/socket.c:747 ____sys_sendmsg+0x75a/0x990 net/socket.c:2493 ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547 __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f1168b1fe5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5dRDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000 Allocated by task 1483: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54168 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx4: Prevent shift wrapping in set_user_sq_size()The ucmd->log_sq_bb_count variable is controlled by the user so thisshift can wrap. Fix it by using check_shl_overflow() in the same waythat it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefinedbehavior in hns_roce_set_user_sq_size()").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38129 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: Fix use-after-free in page_pool_recycle_in_ringsyzbot reported a uaf in page_pool_recycle_in_ring:BUG: KASAN: slab-use-after-free in lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862Read of size 8 at addr ffff8880286045a0 by task syz.0.284/6943CPU: 0 UID: 0 PID: 6943 Comm: syz.0.284 Not tainted 6.13.0-rc3-syzkaller-gdfa94ce54f41 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 lock_release+0x151/0xa30 kernel/locking/lockdep.c:5862 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:165 [inline] _raw_spin_unlock_bh+0x1b/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_produce_bh include/linux/ptr_ring.h:164 [inline] page_pool_recycle_in_ring net/core/page_pool.c:707 [inline] page_pool_put_unrefed_netmem+0x748/0xb00 net/core/page_pool.c:826 page_pool_put_netmem include/net/page_pool/helpers.h:323 [inline] page_pool_put_full_netmem include/net/page_pool/helpers.h:353 [inline] napi_pp_put_page+0x149/0x2b0 net/core/skbuff.c:1036 skb_pp_recycle net/core/skbuff.c:1047 [inline] skb_free_head net/core/skbuff.c:1094 [inline] skb_release_data+0x6c4/0x8a0 net/core/skbuff.c:1125 skb_release_all net/core/skbuff.c:1190 [inline] __kfree_skb net/core/skbuff.c:1204 [inline] sk_skb_reason_drop+0x1c9/0x380 net/core/skbuff.c:1242 kfree_skb_reason include/linux/skbuff.h:1263 [inline] __skb_queue_purge_reason include/linux/skbuff.h:3343 [inline]root cause is:page_pool_recycle_in_ring ptr_ring_produce spin_lock(&r->producer_lock); WRITE_ONCE(r->queue[r->producer++], ptr) //recycle last page to pool page_pool_release page_pool_scrub page_pool_empty_ring ptr_ring_consume page_pool_return_page //release all page __page_pool_destroy free_percpu(pool->recycle_stats); free(pool) //free spin_unlock(&r->producer_lock); //pool->ring uaf read recycle_stat_inc(pool, ring);page_pool can be free while page pool recycle the last page in ring.Add producer-lock barrier to page_pool_release to prevent the pagepool from being free before all pages have been recycled.recycle_stat_inc() is empty when CONFIG_PAGE_POOL_STATS is notenabled, which will trigger Wempty-body build warning. Add definitionfor pool stat macro to fix warning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38159 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix the 'para' buffer size to avoid reading out of boundsSet the size to 6 instead of 2, since 'para' array is passed to'rtw_fw_bt_wifi_control(rtwdev, para[0], ¶[1])', which reads5 bytes:void rtw_fw_bt_wifi_control(struct rtw_dev *rtwdev, u8 op_code, u8 *data){ ... SET_BT_WIFI_CONTROL_DATA1(h2c_pkt, *data); SET_BT_WIFI_CONTROL_DATA2(h2c_pkt, *(data + 1)); ... SET_BT_WIFI_CONTROL_DATA5(h2c_pkt, *(data + 4));Detected using the static analysis tool - Svace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38375 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: ensure the received length does not exceed allocated sizeIn xdp_linearize_page, when reading the following buffers from the ring,we forget to check the received length with the true allocate size. Thiscan lead to an out-of-bound read. This commit adds that missing check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39742 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA: hfi1: fix possible divide-by-zero in find_hw_thread_mask()The function divides number of online CPUs by num_core_siblings, andlater checks the divider by zero. This implies a possibility to getand divide-by-zero runtime error. Fix it by moving the check prior todivision. This also helps to save one indentation level.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39973 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add validation for ring_len paramThe `ring_len` parameter provided by the virtual function (VF)is assigned directly to the hardware memory context (HMC) withoutany validation.To address this, introduce an upper boundary check for both Tx and Rxqueue lengths. The maximum number of descriptors supported by thehardware is 8k-32.Additionally, enforce alignment constraints: Tx rings must be a multipleof 8, and Rx rings must be a multiple of 32.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39977 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:futex: Prevent use-after-free during requeue-PIsyzbot managed to trigger the following race: T1 T2 futex_wait_requeue_pi() futex_do_wait() schedule() futex_requeue() futex_proxy_trylock_atomic() futex_requeue_pi_prepare() requeue_pi_wake_futex() futex_requeue_pi_complete() /* preempt */ * timeout/ signal wakes T1 * futex_requeue_pi_wakeup_sync() // Q_REQUEUE_PI_LOCKED futex_hash_put() // back to userland, on stack futex_q is garbage /* back */ wake_up_state(q->task, TASK_NORMAL);In this scenario futex_wait_requeue_pi() is able to leave without usingfutex_q::lock_ptr for synchronization.This can be prevented by reading futex_q::task before updating thefutex_q::requeue_state. A reference on the task_struct is not neededbecause requeue_pi_wake_futex() is invoked with a spinlock_t held whichimplies a RCU read section.Even if T1 terminates immediately after, the task_struct will remain validduring T2's wake_up_state(). A READ_ONCE on futex_q::task beforefutex_requeue_pi_complete() is enough because it ensures that the variableis read before the state is updated.Read futex_q::task before updating the requeue state, use it for thefollowing wakeup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40018 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: Defer ip_vs_ftp unregister during netns cleanupOn the netns cleanup path, __ip_vs_ftp_exit() may unregister ip_vs_ftpbefore connections with valid cp->app pointers are flushed, leading to ause-after-free.Fix this by introducing a global `exiting_module` flag, set to true inip_vs_ftp_exit() before unregistering the pernet subsystem. In__ip_vs_ftp_exit(), skip ip_vs_ftp unregister if called during netnscleanup (when exiting_module is false) and defer it to__ip_vs_cleanup_batch(), which unregisters all apps after all connectionsare flushed. If called during module exit, unregister ip_vs_ftpimmediately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40019 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: essiv - Check ssize for decryption and in-place encryptionMove the ssize check to the start in essiv_aead_crypt so thatit's also checked for decryption and in-place encryption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40215 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: delete x->tunnel as we delete xThe ipcomp fallback tunnels currently get deleted (from the variouslists and hashtables) as the last user state that needed that fallbackis destroyed (not deleted). If a reference to that user state stillexists, the fallback state will remain on the hashtables/lists,triggering the WARN in xfrm_state_fini. Because of those remainingreferences, the fix in commit f75a2804da39 ("xfrm: destroy xfrm_statesynchronously on net exit path") is not complete.We recently fixed one such situation in TCP due to defered freeing ofskbs (commit 9b6412e6979f ("tcp: drop secpath at the same time as wecurrently drop dst")). This can also happen due to IP reassembly: skbswith a secpath remain on the reassembly queue until netnsdestruction. If we can't guarantee that the queues are flushed by thetime xfrm_state_fini runs, there may still be references to a (user)xfrm_state, preventing the timely deletion of the correspondingfallback state.Instead of chasing each instance of skbs holding a secpath one by one,this patch fixes the issue directly within xfrm, by deleting thefallback state as soon as the last user state depending on it has beendeleted. Destruction will still happen when the final reference isdropped.A separate lockdep class for the fallback state is required sincewe're going to lock x->tunnel while x is locked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40242 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix unlikely race in gdlm_put_lockIn gdlm_put_lock(), there is a small window of time in which theDFL_UNMOUNT flag has been set but the lockspace hasn't been released,yet. In that window, dlm may still call gdlm_ast() and gdlm_bast().To prevent it from dereferencing freed glock objects, only free theglock if the lockspace has actually been released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40258 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix race condition in mptcp_schedule_work()syzbot reported use-after-free in mptcp_schedule_work() [1]Issue here is that mptcp_schedule_work() schedules a work,then gets a refcount on sk->sk_refcnt if the work was scheduled.This refcount will be released by mptcp_worker().[A] if (schedule_work(...)) {[B] sock_hold(sk); return true; }Problem is that mptcp_worker() can run immediately and complete before [B]We need instead : sock_hold(sk); if (schedule_work(...)) return true; sock_put(sk);[1]refcount_t: addition on 0; use-after-free. WARNING: CPU: 1 PID: 29 at lib/refcount.c:25 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:25Call Trace: __refcount_add include/linux/refcount.h:-1 [inline] __refcount_inc include/linux/refcount.h:366 [inline] refcount_inc include/linux/refcount.h:383 [inline] sock_hold include/net/sock.h:816 [inline] mptcp_schedule_work+0x164/0x1a0 net/mptcp/protocol.c:943 mptcp_tout_timer+0x21/0xa0 net/mptcp/protocol.c:2316 call_timer_fn+0x17e/0x5f0 kernel/time/timer.c:1747 expire_timers kernel/time/timer.c:1798 [inline] __run_timers kernel/time/timer.c:2372 [inline] __run_timer_base+0x648/0x970 kernel/time/timer.c:2384 run_timer_base kernel/time/timer.c:2393 [inline] run_timer_softirq+0xb7/0x180 kernel/time/timer.c:2403 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] run_ktimerd+0xcf/0x190 kernel/softirq.c:1138 smpboot_thread_fn+0x542/0xa60 kernel/smpboot.c:160 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40280 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_mon_reinit_self().syzbot reported use-after-free of tipc_net(net)->monitors[]in tipc_mon_reinit_self(). [0]The array is protected by RTNL, but tipc_mon_reinit_self()iterates over it without RTNL.tipc_mon_reinit_self() is called from tipc_net_finalize(),which is always under RTNL except for tipc_net_finalize_work().Let's hold RTNL in tipc_net_finalize_work().[0]:BUG: KASAN: slab-use-after-free in __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]BUG: KASAN: slab-use-after-free in _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162Read of size 1 at addr ffff88805eae1030 by task kworker/0:7/5989CPU: 0 UID: 0 PID: 5989 Comm: kworker/0:7 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Workqueue: events tipc_net_finalize_workCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __kasan_check_byte+0x2a/0x40 mm/kasan/common.c:568 kasan_check_byte include/linux/kasan.h:399 [inline] lock_acquire+0x8d/0x360 kernel/locking/lockdep.c:5842 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xa7/0xf0 kernel/locking/spinlock.c:162 rtlock_slowlock kernel/locking/rtmutex.c:1894 [inline] rwbase_rtmutex_lock_state kernel/locking/spinlock_rt.c:160 [inline] rwbase_write_lock+0xd3/0x7e0 kernel/locking/rwbase_rt.c:244 rt_write_lock+0x76/0x110 kernel/locking/spinlock_rt.c:243 write_lock_bh include/linux/rwlock_rt.h:99 [inline] tipc_mon_reinit_self+0x79/0x430 net/tipc/monitor.c:718 tipc_net_finalize+0x115/0x190 net/tipc/net.c:140 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3319 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3400 kthread+0x70e/0x8a0 kernel/kthread.c:463 ret_from_fork+0x439/0x7d0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 6089: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x1a8/0x320 mm/slub.c:4407 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] tipc_mon_create+0xc3/0x4d0 net/tipc/monitor.c:657 tipc_enable_bearer net/tipc/bearer.c:357 [inline] __tipc_nl_bearer_enable+0xe16/0x13f0 net/tipc/bearer.c:1047 __tipc_nl_compat_doit net/tipc/netlink_compat.c:371 [inline] tipc_nl_compat_doit+0x3bc/0x5f0 net/tipc/netlink_compat.c:393 tipc_nl_compat_handle net/tipc/netlink_compat.c:-1 [inline] tipc_nl_compat_recv+0x83c/0xbe0 net/tipc/netlink_compat.c:1321 genl_family_rcv_msg_doit+0x215/0x300 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x60e/0x790 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x208/0x470 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x846/0xa10 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:729 ____sys_sendmsg+0x508/0x820 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x1a1/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40309 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix UAF on sco_conn_freeBUG: KASAN: slab-use-after-free in sco_conn_free net/bluetooth/sco.c:87 [inline]BUG: KASAN: slab-use-after-free in kref_put include/linux/kref.h:65 [inline]BUG: KASAN: slab-use-after-free in sco_conn_put+0xdd/0x410net/bluetooth/sco.c:107Write of size 8 at addr ffff88811cb96b50 by task kworker/u17:4/352CPU: 1 UID: 0 PID: 352 Comm: kworker/u17:4 Not tainted6.17.0-rc5-g717368f83676 #4 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci13 hci_cmd_sync_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x10b/0x170 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x191/0x550 mm/kasan/report.c:482 kasan_report+0xc4/0x100 mm/kasan/report.c:595 sco_conn_free net/bluetooth/sco.c:87 [inline] kref_put include/linux/kref.h:65 [inline] sco_conn_put+0xdd/0x410 net/bluetooth/sco.c:107 sco_connect_cfm+0xb4/0xae0 net/bluetooth/sco.c:1441 hci_connect_cfm include/net/bluetooth/hci_core.h:2082 [inline] hci_conn_failed+0x20a/0x2e0 net/bluetooth/hci_conn.c:1313 hci_conn_unlink+0x55f/0x810 net/bluetooth/hci_conn.c:1121 hci_conn_del+0xb6/0x1110 net/bluetooth/hci_conn.c:1147 hci_abort_conn_sync+0x8c5/0xbb0 net/bluetooth/hci_sync.c:5689 hci_cmd_sync_work+0x281/0x380 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3236 [inline] process_scheduled_works+0x77e/0x1040 kernel/workqueue.c:3319 worker_thread+0xbee/0x1200 kernel/workqueue.c:3400 kthread+0x3c7/0x870 kernel/kthread.c:463 ret_from_fork+0x13a/0x1e0 arch/x86/kernel/process.c:148 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 31370: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:388 [inline] __kasan_kmalloc+0x82/0x90 mm/kasan/common.c:405 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4382 [inline] __kmalloc_noprof+0x22f/0x390 mm/slub.c:4394 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xae/0x220 net/core/sock.c:2239 sk_alloc+0x34/0x5a0 net/core/sock.c:2295 bt_sock_alloc+0x3c/0x330 net/bluetooth/af_bluetooth.c:151 sco_sock_alloc net/bluetooth/sco.c:562 [inline] sco_sock_create+0xc0/0x350 net/bluetooth/sco.c:593 bt_sock_create+0x161/0x3b0 net/bluetooth/af_bluetooth.c:135 __sock_create+0x3ad/0x780 net/socket.c:1589 sock_create net/socket.c:1647 [inline] __sys_socket_create net/socket.c:1684 [inline] __sys_socket+0xd5/0x330 net/socket.c:1731 __do_sys_socket net/socket.c:1745 [inline] __se_sys_socket net/socket.c:1743 [inline] __x64_sys_socket+0x7a/0x90 net/socket.c:1743 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xc7/0x240 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 31374: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x70 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:243 [inline] __kasan_slab_free+0x3d/0x50 mm/kasan/common.c:275 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2428 [inline] slab_free mm/slub.c:4701 [inline] kfree+0x199/0x3b0 mm/slub.c:4900 sk_prot_free net/core/sock.c:2278 [inline] __sk_destruct+0x4aa/0x630 net/core/sock.c:2373 sco_sock_release+0x2ad/0x300 net/bluetooth/sco.c:1333 __sock_release net/socket.c:649 [inline] sock_close+0xb8/0x230 net/socket.c:1439 __fput+0x3d1/0x9e0 fs/file_table.c:468 task_work_run+0x206/0x2a0 kernel/task_work.c:227 get_signal+0x1201/0x1410 kernel/signal.c:2807 arch_do_signal_or_restart+0x34/0x740 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x68/0xc0 kernel/entry/common.c:40 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] s---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40342 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fc: use lock accessing port_state and rport statenvme_fc_unregister_remote removes the remote port on a lport object atany point in time when there is no active association. This races withwith the reconnect logic, because nvme_fc_create_association is nottaking a lock to check the port_state and atomically increase theactive count on the rport.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-58143 Severity: Important CVSS3 score: 7.0

Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs < 4.16.7_04-150400.4.75.1 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2025-68223 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: delete radeon_fence_process in is_signaled, no deadlockDelete the attempt to progress the queue when checking if fence issignaled. This avoids deadlock.dma-fence_ops::signaled can be called with the fence lock in unknownstate. For radeon, the fence lock is also the wait queue lock. This cancause a self deadlock when signaled() tries to make forward progress onthe wait queue. But advancing the queue is unneeded because incorrectlyreturning false from signaled() is perfectly acceptable.(cherry picked from commit 527ba26e50ec2ca2be9c7c82f3ad42998a75d0db)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68285 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix potential use-after-free in have_mon_and_osd_map()The wait loop in __ceph_open_session() can race with the clientreceiving a new monmap or osdmap shortly after the initial map isreceived. Both ceph_monc_handle_map() and handle_one_map() installa new map immediately after freeing the old one kfree(monc->monmap); monc->monmap = monmap; ceph_osdmap_destroy(osdc->osdmap); osdc->osdmap = newmap;under client->monc.mutex and client->osdc.lock respectively, butbecause neither is taken in have_mon_and_osd_map() it's possible forclient->monc.monmap->epoch and client->osdc.osdmap->epoch arms in client->monc.monmap && client->monc.monmap->epoch && client->osdc.osdmap && client->osdc.osdmap->epoch;condition to dereference an already freed map. This happens to bereproducible with generic/395 and generic/397 with KASAN enabled: BUG: KASAN: slab-use-after-free in have_mon_and_osd_map+0x56/0x70 Read of size 4 at addr ffff88811012d810 by task mount.ceph/13305 CPU: 2 UID: 0 PID: 13305 Comm: mount.ceph Not tainted 6.14.0-rc2-build2+ #1266 ... Call Trace: have_mon_and_osd_map+0x56/0x70 ceph_open_session+0x182/0x290 ceph_get_tree+0x333/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 13305: ceph_osdmap_alloc+0x16/0x130 ceph_osdc_init+0x27a/0x4c0 ceph_create_client+0x153/0x190 create_fs_client+0x50/0x2a0 ceph_get_tree+0xff/0x680 vfs_get_tree+0x49/0x180 do_new_mount+0x1a3/0x2d0 path_mount+0x6dd/0x730 do_mount+0x99/0xe0 __do_sys_mount+0x141/0x180 do_syscall_64+0x9f/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 9475: kfree+0x212/0x290 handle_one_map+0x23c/0x3b0 ceph_osdc_handle_map+0x3c9/0x590 mon_dispatch+0x655/0x6f0 ceph_con_process_message+0xc3/0xe0 ceph_con_v1_try_read+0x614/0x760 ceph_con_workfn+0x2de/0x650 process_one_work+0x486/0x7c0 process_scheduled_works+0x73/0x90 worker_thread+0x1c8/0x2a0 kthread+0x2ec/0x300 ret_from_fork+0x24/0x40 ret_from_fork_asm+0x1a/0x30Rewrite the wait loop to check the above condition directly withclient->monc.mutex and client->osdc.lock taken as appropriate. Whileat it, improve the timeout handling (previously mount_timeout could beexceeded in case wait_event_interruptible_timeout() slept more thanonce) and access client->auth_err under client->monc.mutex to matchhow it's set in finish_auth().monmap_show() and osdmap_show() now take the respective lock beforeaccessing the map as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68732 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:gpu: host1x: Fix race in syncpt alloc/freeFix race condition between host1x_syncpt_alloc()and host1x_syncpt_put() by using kref_put_mutex()instead of kref_put() + manual mutex locking.This ensures no thread can acquire thesyncpt_mutex after the refcount drops to zerobut before syncpt_release acquires it.This prevents races where syncpoints couldbe allocated while still being cleaned upfrom a previous release.Remove explicit mutex locking in syncpt_releaseas kref_put_mutex() handles this atomically.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68781 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: phy: fsl-usb: Fix use-after-free in delayed work during device removalThe delayed work item otg_event is initialized in fsl_otg_conf() andscheduled under two conditions:1. When a host controller binds to the OTG controller.2. When the USB ID pin state changes (cable insertion/removal).A race condition occurs when the device is removed via fsl_otg_remove():the fsl_otg instance may be freed while the delayed work is still pendingor executing. This leads to use-after-free when the work functionfsl_otg_event() accesses the already freed memory.The problematic scenario:(detach thread) | (delayed work)fsl_otg_remove() | kfree(fsl_otg_dev) //FREE| fsl_otg_event() | og = container_of(...) //USE | og-> //USEFix this by calling disable_delayed_work_sync() in fsl_otg_remove()before deallocating the fsl_otg structure. This ensures the delayed workis properly canceled and completes execution prior to memory deallocation.This bug was identified through static analysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68804 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:platform/chrome: cros_ec_ishtp: Fix UAF after unbinding driverAfter unbinding the driver, another kthread `cros_ec_console_log_work`is still accessing the device, resulting an UAF and crash.The driver doesn't unregister the EC device in .remove() which shouldshutdown sub-devices synchronously. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71089 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:iommu: disable SVA when CONFIG_X86 is setPatch series "Fix stale IOTLB entries for kernel address space", v7.This proposes a fix for a security vulnerability related to IOMMU SharedVirtual Addressing (SVA). In an SVA context, an IOMMU can cache kernelpage table entries. When a kernel page table page is freed andreallocated for another purpose, the IOMMU might still hold stale,incorrect entries. This can be exploited to cause a use-after-free orwrite-after-free condition, potentially leading to privilege escalation ordata corruption.This solution introduces a deferred freeing mechanism for kernel pagetable pages, which provides a safe window to notify the IOMMU toinvalidate its caches before the page is reused.This patch (of 8):In the IOMMU Shared Virtual Addressing (SVA) context, the IOMMU hardwareshares and walks the CPU's page tables. The x86 architecture maps thekernel's virtual address space into the upper portion of every process'spage table. Consequently, in an SVA context, the IOMMU hardware can walkand cache kernel page table entries.The Linux kernel currently lacks a notification mechanism for kernel pagetable changes, specifically when page table pages are freed and reused. The IOMMU driver is only notified of changes to user virtual addressmappings. This can cause the IOMMU's internal caches to retain staleentries for kernel VA.Use-After-Free (UAF) and Write-After-Free (WAF) conditions arise whenkernel page table pages are freed and later reallocated. The IOMMU couldmisinterpret the new data as valid page table entries. The IOMMU mightthen walk into attacker-controlled memory, leading to arbitrary physicalmemory DMA access or privilege escalation. This is also aWrite-After-Free issue, as the IOMMU will potentially continue to writeAccessed and Dirty bits to the freed memory while attempting to walk thestale page tables.Currently, SVA contexts are unprivileged and cannot access kernelmappings. However, the IOMMU will still walk kernel-only page tables allthe way down to the leaf entries, where it realizes the mapping is for thekernel and errors out. This means the IOMMU still caches theseintermediate page table entries, making the described vulnerability a realconcern.Disable SVA on x86 architecture until the IOMMU can receive notificationto flush the paging cache before freeing the CPU kernel page table pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71112 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: add VLAN id validation before usingCurrently, the VLAN id may be used without validation whenreceive a VLAN configuration mailbox from VF. The length ofvlan_del_fail_bmap is BITS_TO_LONGS(VLAN_N_VID). It may causeout-of-bounds memory access once the VLAN id is bigger thanor equal to VLAN_N_VID.Therefore, VLAN id needs to be checked to ensure it is withinthe range of VLAN_N_VID.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71128 Severity: Important CVSS3 score: 7.0

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: Initialize options_len before referencing options.The struct ip_tunnel_info has a flexible array member namedoptions that is protected by a counted_by(options_len)attribute.The compiler will use this information to enforce runtime boundschecking deployed by FORTIFY_SOURCE string helpers.As laid out in the GCC documentation, the counter must beinitialized before the first reference to the flexible arraymember.After scanning through the files that use struct ip_tunnel_infoand also refer to options or options_len, it appears the normalcase is to use the ip_tunnel_info_opts_set() helper.Said helper would initialize options_len properly before copyingdata into options, however in the GRE ERSPAN code a partialupdate is done, preventing the use of the helper function.Before this change the handling of ERSPAN traffic in GRE tunnelswould cause a kernel panic when the kernel is compiled withGCC 15+ and having FORTIFY_SOURCE configured:memcpy: detected buffer overflow: 4 byte write of buffer size 0Call Trace: __fortify_panic+0xd/0xf erspan_rcv.cold+0x68/0x83 ? ip_route_input_slow+0x816/0x9d0 gre_rcv+0x1b2/0x1c0 gre_rcv+0x8e/0x100 ? raw_v4_input+0x2a0/0x2b0 ip_protocol_deliver_rcu+0x1ea/0x210 ip_local_deliver_finish+0x86/0x110 ip_local_deliver+0x65/0x110 ? ip_rcv_finish_core+0xd6/0x360 ip_rcv+0x186/0x1a0Reported-at: https://launchpad.net/bugs/2129580

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49940 Severity: Moderate CVSS3 score: 6.8

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: prevent possible tunnel refcount underflowWhen a session is created, it sets a backpointer to its tunnel. Whenthe session refcount drops to 0, l2tp_session_free drops the tunnelrefcount if session->tunnel is non-NULL. However, session->tunnel isset in l2tp_session_create, before the tunnel refcount is incrementedby l2tp_session_register, which leaves a small window wheresession->tunnel is non-NULL when the tunnel refcount hasn't beenbumped.Moving the assignment to l2tp_session_register is trivial butl2tp_session_create calls l2tp_session_set_header_len which usessession->tunnel to get the tunnel's encap. Add an encap arg tol2tp_session_set_header_len to avoid using session->tunnel.If l2tpv3 sessions have colliding IDs, it is possible forl2tp_v3_session_get to race with l2tp_session_register and fetch asession which doesn't yet have session->tunnel set. Add a check forthis case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-15444 Severity: Moderate CVSS3 score: 6.8

Description: Crypt::Sodium::XS module versions prior to 0.000042, for Perl, include a vulnerable version of libsodiumlibsodium <= 1.0.20 or a version of libsodium released before December 30, 2025 contains a vulnerability documented as CVE-2025-69277 https://www.cve.org/CVERecord?id=CVE-2025-69277 .The libsodium vulnerability states:In atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.0.000042 includes a version of libsodium updated to 1.0.20-stable, released January 3, 2026, which includes a fix for the vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).

CVE-2025-40345 Severity: Moderate CVSS3 score: 6.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: storage: sddr55: Reject out-of-bound new_pbaDiscovered by Atuin - Automated Vulnerability Discovery Engine.new_pba comes from the status packet returned after each write.A bogus device could report values beyond the block count derivedfrom info->capacity, letting the driver walk off the end ofpba_to_lba[] and corrupt heap memory.Reject PBAs that exceed the computed block count and fail thetransfer so we avoid touching out-of-range mapping entries.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-58147 Severity: Moderate CVSS3 score: 6.8

Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]Some Viridian hypercalls can specify a mask of vCPU IDs as an input, inone of three formats. Xen has boundary checking bugs with all threeformats, which can cause out-of-bounds reads and writes while processingthe inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs < 4.16.7_04-150400.4.75.1 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2025-58148 Severity: Moderate CVSS3 score: 6.8

Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]Some Viridian hypercalls can specify a mask of vCPU IDs as an input, inone of three formats. Xen has boundary checking bugs with all threeformats, which can cause out-of-bounds reads and writes while processingthe inputs. * CVE-2025-58147. Hypercalls using the HV_VP_SET Sparse format can cause vpmask_set() to write out of bounds when converting the bitmap to Xen's format. * CVE-2025-58148. Hypercalls using any input format can cause send_ipi() to read d->vcpu[] out-of-bounds, and operate on a wild vCPU pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs < 4.16.7_04-150400.4.75.1 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2025-6069 Severity: Moderate CVSS3 score: 6.8

Description: The html.parser.HTMLParser class had worse-case quadratic complexity when processing certain crafted malformed inputs potentially leading to amplified denial-of-service.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-64505 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. Prior to version 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_do_quantize function when processing PNG files with malformed palette indices. The vulnerability occurs when palette_lookup array bounds are not validated against externally-supplied image data, allowing an attacker to craft a PNG file with out-of-range palette indices that trigger out-of-bounds memory access. This issue has been patched in version 1.6.51.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).

CVE-2025-64506 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, a heap buffer over-read vulnerability exists in libpng's png_write_image_8bit function when processing 8-bit images through the simplified write API with convert_to_8bit enabled. The vulnerability affects 8-bit grayscale+alpha, RGB/RGBA, and images with incomplete row data. A conditional guard incorrectly allows 8-bit input to enter code expecting 16-bit input, causing reads up to 2 bytes beyond allocated buffer boundaries. This issue has been patched in version 1.6.51.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).

CVE-2025-64720 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, an out-of-bounds read vulnerability exists in png_image_read_composite when processing palette images with PNG_FLAG_OPTIMIZE_ALPHA enabled. The palette compositing code in png_init_read_transformations incorrectly applies background compositing during premultiplication, violating the invariant component ≤ alpha x 257 required by the simplified PNG API. This issue has been patched in version 1.6.51.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).

CVE-2025-65018 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From version 1.6.0 to before 1.6.51, there is a heap buffer overflow vulnerability in the libpng simplified API function png_image_finish_read when processing 16-bit interlaced PNGs with 8-bit output format. Attacker-crafted interlaced PNG files cause heap writes beyond allocated buffer bounds. This issue has been patched in version 1.6.51.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 < 1.6.34-150000.3.12.1 (version in image is 1.6.34-3.9.1).

CVE-2026-22185 Severity: Moderate CVSS3 score: 6.8

Description: OpenLDAP Lightning Memory-Mapped Database (LMDB) versions up to and including 0.9.14, prior to commit 8e1fda8, contain a heap buffer underflow in the readline() function of mdb_load. When processing malformed input containing an embedded NUL byte, an unsigned offset calculation can underflow and cause an out-of-bounds read of one byte before the allocated heap buffer. This can cause mdb_load to crash, leading to a limited denial-of-service condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libldap-2_4-2 > 0-0 (version in image is 2.4.46-150200.14.17.1).

CVE-2026-22801 Severity: Moderate CVSS3 score: 6.8

Description: LIBPNG is a reference library for use in applications that read, create, and manipulate PNG (Portable Network Graphics) raster image files. From 1.6.26 to 1.6.53, there is an integer truncation in the libpng simplified write API functions png_write_image_16bit and png_write_image_8bit causes heap buffer over-read when the caller provides a negative row stride (for bottom-up image layouts) or a stride exceeding 65535 bytes. The bug was introduced in libpng 1.6.26 (October 2016) by casts added to silence compiler warnings on 16-bit systems. This vulnerability is fixed in 1.6.54.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpng16-16 > 0-0 (version in image is 1.6.34-3.9.1).

CVE-2013-4235 Severity: Moderate CVSS3 score: 6.7

Description: shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
login_defs > 0-0 (version in image is 4.8.1-150400.10.24.1).

CVE-2022-48733 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free after failure to create a snapshotAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure andthen attach it to the transaction's list of pending snapshots. After thatwe call btrfs_commit_transaction(), and if that returns an error we jumpto 'fail' label, where we kfree() the pending snapshot structure. This canresult in a later use-after-free of the pending snapshot:1) We allocated the pending snapshot and added it to the transaction's list of pending snapshots;2) We call btrfs_commit_transaction(), and it fails either at the first call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups(). In both cases, we don't abort the transaction and we release our transaction handle. We jump to the 'fail' label and free the pending snapshot structure. We return with the pending snapshot still in the transaction's list;3) Another task commits the transaction. This time there's no error at all, and then during the transaction commit it accesses a pointer to the pending snapshot structure that the snapshot creation task has already freed, resulting in a user-after-free.This issue could actually be detected by smatch, which produced thefollowing warning: fs/btrfs/ioctl.c:843 create_snapshot() warn: '&pending_snapshot->list' not removed from listSo fix this by not having the snapshot creation ioctl directly add thepending snapshot to the transaction's list. Instead add the pendingsnapshot to the transaction handle, and then at btrfs_commit_transaction()we add the snapshot to the list only when we can guarantee that any errorreturned after that point will result in a transaction abort, in whichcase the ioctl code can safely free the pending snapshot and no one canaccess it anymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49961 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZEROPrecision markers need to be propagated whenever we have an ARG_CONST_*style argument, as the verifier cannot consider imprecise scalars to beequivalent for the purposes of states_equal check when such argumentsrefine the return value (in this case, set mem_size for PTR_TO_MEM). Theresultant mem_size for the R0 is derived from the constant value, and ifthe verifier incorrectly prunes states considering them equivalent wheresuch arguments exist (by seeing that both registers have reg->precise asfalse in regsafe), we can end up with invalid programs passing theverifier which can do access beyond what should have been the correctmem_size in that explored state.To show a concrete example of the problem:0000000000000000 : 0: r2 = *(u32 *)(r1 + 80) 1: r1 = *(u32 *)(r1 + 76) 2: r3 = r1 3: r3 += 4 4: if r3 > r2 goto +18 5: w2 = 0 6: *(u32 *)(r1 + 0) = r2 7: r1 = *(u32 *)(r1 + 0) 8: r2 = 1 9: if w1 == 0 goto +1 10: r2 = -10000000000000058 : 11: r1 = 0 ll 13: r3 = 0 14: call bpf_ringbuf_reserve 15: if r0 == 0 goto +7 16: r1 = r0 17: r1 += 16777215 18: w2 = 0 19: *(u8 *)(r1 + 0) = r2 20: r1 = r0 21: r2 = 0 22: call bpf_ringbuf_submit00000000000000b8 : 23: w0 = 0 24: exitFor the first case, the single line execution's exploration will prunethe search at insn 14 for the branch insn 9's second leg as it will beverified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 willalways be 0 so at runtime we don't get error for being greater thanUINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe justsees reg->precise as false for both r2 registers in both states, henceconsiders them equal for purposes of states_equal.If we propagated precise markers using the backtracking support, wewould use the precise marking to then ensure that old r2 (UINT_MAX) waswithin the new r2 (1) and this would never be true, so the verificationwould rightfully fail.The end result is that the out of bounds access at instruction 19 wouldbe permitted without this fix.Note that reg->precise is always set to true when user does not haveCAP_BPF (or when subprog count is greater than 1 (i.e. use of any staticor global functions)), hence this is only a problem when precision marksneed to be explicitly propagated (i.e. privileged users with CAP_BPF).A simplified test case has been included in the next patch to preventfuture regressions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50492 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: fix use-after-free on probe deferralThe bridge counter was never reset when tearing down the DRM device sothat stale pointers to deallocated structures would be accessed on thenext tear down (e.g. after a second late bind deferral).Given enough bridges and a few probe deferrals this could currently alsolead to data beyond the bridge array being corrupted.Patchwork: https://patchwork.freedesktop.org/patch/502665/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52620 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow timeout for anonymous setsNever used from userspace, disallow these parameters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53338 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:lwt: Fix return values of BPF xmit opsBPF encap ops can return different types of positive values, such likeNET_RX_DROP, NET_XMIT_CN, NETDEV_TX_BUSY, and so on, from functionskb_do_redirect and bpf_lwt_xmit_reroute. At the xmit hook, such returnvalues would be treated implicitly as LWTUNNEL_XMIT_CONTINUE inip(6)_finish_output2. When this happens, skbs that have been freed wouldcontinue to the neighbor subsystem, causing use-after-free bug andkernel crashes.To fix the incorrect behavior, skb_do_redirect return values can besimply discarded, the same as tc-egress behavior. On the other hand,bpf_lwt_xmit_reroute returns useful errors to local senders, e.g. PMTUinformation. Thus convert its return values to avoid the conflict withLWTUNNEL_XMIT_CONTINUE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53619 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: Avoid nf_ct_helper_hash uses after freeIf nf_conntrack_init_start() fails (for example due to aregister_nf_conntrack_bpf() failure), the nf_conntrack_helper_fini()clean-up path frees the nf_ct_helper_hash map.When built with NF_CONNTRACK=y, further netfilter modules (e.g:netfilter_conntrack_ftp) can still be loaded and callnf_conntrack_helpers_register(), independently of whether nf_conntrackinitialized correctly. This accesses the nf_ct_helper_hash danglingpointer and causes a uaf, possibly leading to random memory corruption.This patch guards nf_conntrack_helper_register() from accessing a freedor uninitialized nf_ct_helper_hash pointer and fixes possibleuses-after-free when loading a conntrack module.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-6817 Severity: Moderate CVSS3 score: 6.7

Description: A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.The function nft_pipapo_walk did not skip inactive elements during set walk which could lead double deactivations of PIPAPO (Pile Packet Policies) elements, leading to use-after-free.We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36883 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto set s.len with a larger than allocated length for the variable array.Fix it by reading max_gen_ptrs only once in net_alloc_generic. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38630 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_triggerWhen the cpu5wdt module is removing, the origin code uses del_timer() tode-activate the timer. If the timer handler is running, del_timer() couldnot stop it and will return directly. If the port region is released byrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()to write into the region that is released, the use-after-free bug willhappen.Change del_timer() to timer_shutdown_sync() in order that the timer handlercould be finished before the port region is released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46738 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix use-after-free when removing resource in vmci_resource_remove()When removing a resource from vmci_resource_table invmci_resource_remove(), the search is performed using the resourcehandle by comparing context and resource fields.It is possible though to create two resources with different typesbut same handle (same context and resource fields).When trying to remove one of the resources, vmci_resource_remove()may not remove the intended one, but the object will still be freedas in the case of the datagram type in vmci_datagram_destroy_handle().vmci_resource_table will still hold a pointer to this freed resourceleading to a use-after-free vulnerability.BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0This change ensures the type is also checked when removingthe resource from vmci_resource_table in vmci_resource_remove().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49861 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix helper writes to read-only mapsLonial found an issue that despite user- and BPF-side frozen BPF map(like in case of .rodata), it was still possible to write into it froma BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT}as arguments.In check_func_arg() when the argument is as mentioned, the meta->raw_modeis never set. Later, check_helper_mem_access(), under the case ofPTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for thesubsequent call to check_map_access_type() and given the BPF map isread-only it succeeds.The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINITwhen results are written into them as opposed to read out of them. Thelatter indicates that it's okay to pass a pointer to uninitialized memoryas the memory is written to anyway.However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEMjust with additional alignment requirement. So it is better to just getrid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse thefixed size memory types. For this, add MEM_ALIGNED to additionally ensurealignment given these helpers write directly into the args via * = val.The .arg*_size has been initialized reflecting the actual sizeof(*).MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotatedargument types, since in !MEM_FIXED_SIZE cases the verifier does not knowthe buffer size a priori and therefore cannot blindly write * = val.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56551 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix usage slab after free[ +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147[ +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1[ +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020[ +0.000016] Call Trace:[ +0.000008] [ +0.000009] dump_stack_lvl+0x76/0xa0[ +0.000017] print_report+0xce/0x5f0[ +0.000017] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] ? srso_return_thunk+0x5/0x5f[ +0.000015] ? kasan_complete_mode_report_info+0x72/0x200[ +0.000016] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000019] kasan_report+0xbe/0x110[ +0.000015] ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000023] __asan_report_load8_noabort+0x14/0x30[ +0.000014] drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000016] ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched][ +0.000020] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? enable_work+0x124/0x220[ +0.000015] ? __pfx_enable_work+0x10/0x10[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? free_large_kmalloc+0x85/0xf0[ +0.000016] drm_sched_entity_destroy+0x18/0x30 [gpu_sched][ +0.000020] amdgpu_vce_sw_fini+0x55/0x170 [amdgpu][ +0.000735] ? __kasan_check_read+0x11/0x20[ +0.000016] vce_v4_0_sw_fini+0x80/0x110 [amdgpu][ +0.000726] amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu][ +0.000679] ? mutex_unlock+0x80/0xe0[ +0.000017] ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu][ +0.000662] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? __kasan_check_write+0x14/0x30[ +0.000013] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? mutex_unlock+0x80/0xe0[ +0.000016] amdgpu_driver_release_kms+0x16/0x80 [amdgpu][ +0.000663] drm_minor_release+0xc9/0x140 [drm][ +0.000081] drm_release+0x1fd/0x390 [drm][ +0.000082] __fput+0x36c/0xad0[ +0.000018] __fput_sync+0x3c/0x50[ +0.000014] __x64_sys_close+0x7d/0xe0[ +0.000014] x64_sys_call+0x1bc6/0x2680[ +0.000014] do_syscall_64+0x70/0x130[ +0.000014] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit_to_user_mode+0x60/0x190[ +0.000015] ? srso_return_thunk+0x5/0x5f[ +0.000014] ? irqentry_exit+0x43/0x50[ +0.000012] ? srso_return_thunk+0x5/0x5f[ +0.000013] ? exc_page_fault+0x7c/0x110[ +0.000015] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ +0.000014] RIP: 0033:0x7ffff7b14f67[ +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff[ +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003[ +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67[ +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003[ +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000[ +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8[ +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040[ +0.000020] [ +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:[ +0.000014] kasan_save_stack+0x28/0x60[ +0.000008] kasan_save_track+0x18/0x70[ +0.000007] kasan_save_alloc_info+0x38/0x60[ +0.000007] __kasan_kmalloc+0xc1/0xd0[ +0.000007] kmalloc_trace_noprof+0x180/0x380[ +0.000007] drm_sched_init+0x411/0xec0 [gpu_sched][ +0.000012] amdgpu_device_init+0x695f/0xa610 [amdgpu][ +0.000658] amdgpu_driver_load_kms+0x1a/0x120 [amdgpu][ +0.000662] amdgpu_pci_p---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56708 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/igen6: Avoid segmentation fault on module unloadThe segmentation fault happens because:During modprobe:1. In igen6_probe(), igen6_pvt will be allocated with kzalloc()2. In igen6_register_mci(), mci->pvt_info will point to &igen6_pvt->imc[mc]During rmmod:1. In mci_release() in edac_mc.c, it will kfree(mci->pvt_info)2. In igen6_remove(), it will kfree(igen6_pvt);Fix this issue by setting mci->pvt_info to NULL to avoid the doublekfree.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57795 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Remove the direct link to net_deviceThe similar patch in siw is in the link:https://git.kernel.org/rdma/rdma/c/16b87037b48889This problem also occurred in RXE. The following analyze this problem.In the following Call Traces:"BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0 net/core/dev.c:8782Read of size 4 at addr ffff8880554640b0 by task kworker/1:4/5295CPU: 1 UID: 0 PID: 5295 Comm: kworker/1:4 Not tainted6.12.0-rc3-syzkaller-00399-g9197b73fd7bb #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 09/13/2024Workqueue: infiniband ib_cache_event_taskCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 dev_get_flags+0x188/0x1d0 net/core/dev.c:8782 rxe_query_port+0x12d/0x260 drivers/infiniband/sw/rxe/rxe_verbs.c:60 __ib_query_port drivers/infiniband/core/device.c:2111 [inline] ib_query_port+0x168/0x7d0 drivers/infiniband/core/device.c:2143 ib_cache_update+0x1a9/0xb80 drivers/infiniband/core/cache.c:1494 ib_cache_event_task+0xf3/0x1e0 drivers/infiniband/core/cache.c:1568 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 "1). In the link [1]," infiniband syz2: set down"This means that on 839.350575, the event ib_cache_event_task was sent andiqueued in ib_wq.2). In the link [1]," team0 (unregistering): Port device team_slave_0 removed"It indicates that before 843.251853, the net device should be freed.3). In the link [1]," BUG: KASAN: slab-use-after-free in dev_get_flags+0x188/0x1d0"This means that on 850.559070, this slab-use-after-free problem occurred.In all, on 839.350575, the event ib_cache_event_task was sent and queuedin ib_wq,before 843.251853, the net device veth was freed.on 850.559070, this event was executed, and the mentioned freed net devicewas called. Thus, the above call trace occurred.[1] https://syzkaller.appspot.com/x/log.txt?x=12e7025f980000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57857 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/siw: Remove direct link to net_deviceDo not manage a per device direct link to net_device. Relyon associated ib_devices net_device management, not doublingthe effort locally. A badly managed local link to net_devicewas causing a 'KASAN: slab-use-after-free' exception duringsiw_query_port() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57929 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm array: fix releasing a faulty array block twice in dm_array_cursor_endWhen dm_bm_read_lock() fails due to locking or checksum errors, itreleases the faulty block implicitly while leaving an invalid outputpointer behind. The caller of dm_bm_read_lock() should not operate onthis invalid dm_block pointer, or it will lead to undefined result.For example, the dm_array_cursor incorrectly caches the invalid pointeron reading a faulty array block, causing a double release indm_array_cursor_end(), then hitting the BUG_ON in dm-bufio cache_put().Reproduce steps:1. initialize a cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"2. wipe the second array block offlinedmsteup remove cache cmeta cdata corigmapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try reopen the cache devicedmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc $262144"dmsetup create cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"Kernel logs:(snip)device-mapper: array: array_block_check failed: blocknr 0 != wanted 10device-mapper: block manager: array validator check failed for block 10device-mapper: array: get_ablock faileddevice-mapper: cache metadata: dm_array_cursor_next for mapping failed------------[ cut here ]------------kernel BUG at drivers/md/dm-bufio.c:638!Fix by setting the cached block pointer to NULL on errors.In addition to the reproducer described above, this fix can beverified using the "array_cursor/damaged" test in dm-unit: dm-unit run /pdata/array_cursor/damaged --kernel-dir

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-15366 Severity: Moderate CVSS3 score: 6.7

Description: The imaplib module, when passed a user-controlled command, can have additional commands injected using newlines. Mitigation rejects commands containing control characters.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-15367 Severity: Moderate CVSS3 score: 6.7

Description: The poplib module, when passed a user-controlled command, can haveadditional commands injected using newlines. Mitigation rejects commandscontaining control characters.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-21739 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix use-after free in init error and remove pathsdevm_blk_crypto_profile_init() registers a cleanup handler to run whenthe associated (platform-) device is being released. For UFS, thecrypto private data and pointers are stored as part of the ufs_hba'sdata structure 'struct ufs_hba::crypto_profile'. This structure isallocated as part of the underlying ufshcd and therefore Scsi_hostallocation.During driver release or during error handling in ufshcd_pltfrm_init(),this structure is released as part of ufshcd_dealloc_host() before the(platform-) device associated with the crypto call above is released.Once this device is released, the crypto cleanup code will run, usingthe just-released 'struct ufs_hba::crypto_profile'. This causes ause-after-free situation: Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blk_crypto_profile_destroy_callback+0x28/0x70 devm_action_release+0x1c/0x30 release_nodes+0x6c/0x108 devres_release_all+0x98/0x100 device_unbind_cleanup+0x20/0x70 really_probe+0x218/0x2d0In other words, the initialisation code flow is: platform-device probe ufshcd_pltfrm_init() ufshcd_alloc_host() scsi_host_alloc() allocation of struct ufs_hba creation of scsi-host devices devm_blk_crypto_profile_init() devm registration of cleanup handler using platform-deviceand during error handling of ufshcd_pltfrm_init() or during driverremoval: ufshcd_dealloc_host() scsi_host_put() put_device(scsi-host) release of struct ufs_hba put_device(platform-device) crypto cleanup handlerTo fix this use-after free, change ufshcd_alloc_host() to register adevres action to automatically cleanup the underlying SCSI device onufshcd destruction, without requiring explicit calls toufshcd_dealloc_host(). This way: * the crypto profile and all other ufs_hba-owned resources are destroyed before SCSI (as they've been registered after) * a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect * EXPORT_SYMBOL_GPL(ufshcd_dealloc_host) can be removed fully as it's not needed anymore * no future drivers using ufshcd_alloc_host() could ever forget adding the cleanup

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38061 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: pktgen: fix access outside of user given buffer in pktgen_thread_write()Honour the user given buffer size for the strn_len() calls (otherwisestrn_len() will access memory outside of the user given buffer).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38346 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix UAF when lookup kallsym after ftrace disabledThe following issue happens with a buggy module:BUG: unable to handle page fault for address: ffffffffc05d0218PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0Oops: Oops: 0000 [#1] SMP KASAN PTITainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSRIP: 0010:sized_strscpy+0x81/0x2f0RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffffffc0601010 RCX: dffffc0000000000RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2dRBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68R10: ffff88812608d82d R11: ffff88812608d810 R12: 0000000000000038R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeffFS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue may happen as follows:(1) Add kprobe tracepoint;(2) insmod test.ko;(3) Module triggers ftrace disabled;(4) rmmod test.ko;(5) cat /proc/kallsyms; --> Will trigger UAF as test.ko already removed;ftrace_mod_get_kallsym()...strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);...The problem is when a module triggers an issue with ftrace andsets ftrace_disable. The ftrace_disable is set when an anomaly isdiscovered and to prevent any more damage, ftrace stops all textmodification. The issue that happened was that the ftrace_disable stopsmore than just the text modification.When a module is loaded, its init functions can also be traced. Becausekallsyms deletes the init functions after a module has loaded, ftracesaves them when the module is loaded and function tracing is enabled. Thisallows the output of the function trace to show the init function namesinstead of just their raw memory addresses.When a module is removed, ftrace_release_mod() is called, and ifftrace_disable is set, it just returns without doing anything more. Theproblem here is that it leaves the mod_list still around and if kallsymsis called, it will call into this code and access the module memory thathas already been freed as it will return: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN);Where the "mod" no longer exists and triggers a UAF bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39940 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm-stripe: fix a possible integer overflowThere's a possible integer overflow in stripe_io_hints if we have toolarge chunk size. Test if the overflow happened, and if it did, don't setlimits->io_min and limits->io_opt;

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68801 Severity: Moderate CVSS3 score: 6.7

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_router: Fix neighbour use-after-freeWe sometimes observe use-after-free when dereferencing a neighbour [1].The problem seems to be that the driver stores a pointer to theneighbour, but without holding a reference on it. A reference is onlytaken when the neighbour is used by a nexthop.Fix by simplifying the reference counting scheme. Always take areference when storing a neighbour pointer in a neighbour entry. Avoidtaking a referencing when the neighbour is used by a nexthop as theneighbour entry associated with the nexthop already holds a reference.Tested by running the test that uncovered the problem over 300 times.Without this patch the problem was reproduced after a handful ofiterations.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_neigh_entry_update+0x2d4/0x310Read of size 8 at addr ffff88817f8e3420 by task ip/3929CPU: 3 UID: 0 PID: 3929 Comm: ip Not tainted 6.18.0-rc4-virtme-g36b21a067510 #3 PREEMPT(full)Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023Call Trace: dump_stack_lvl+0x6f/0xa0 print_address_description.constprop.0+0x6e/0x300 print_report+0xfc/0x1fb kasan_report+0xe4/0x110 mlxsw_sp_neigh_entry_update+0x2d4/0x310 mlxsw_sp_router_rif_gone_sync+0x35f/0x510 mlxsw_sp_rif_destroy+0x1ea/0x730 mlxsw_sp_inetaddr_port_vlan_event+0xa1/0x1b0 __mlxsw_sp_inetaddr_lag_event+0xcc/0x130 __mlxsw_sp_inetaddr_event+0xf5/0x3c0 mlxsw_sp_router_netdevice_event+0x1015/0x1580 notifier_call_chain+0xcc/0x150 call_netdevice_notifiers_info+0x7e/0x100 __netdev_upper_dev_unlink+0x10b/0x210 netdev_upper_dev_unlink+0x79/0xa0 vrf_del_slave+0x18/0x50 do_set_master+0x146/0x7d0 do_setlink.isra.0+0x9a0/0x2880 rtnl_newlink+0x637/0xb20 rtnetlink_rcv_msg+0x6fe/0xb90 netlink_rcv_skb+0x123/0x380 netlink_unicast+0x4a3/0x770 netlink_sendmsg+0x75b/0xc90 __sock_sendmsg+0xbe/0x160 ____sys_sendmsg+0x5b2/0x7d0 ___sys_sendmsg+0xfd/0x180 __sys_sendmsg+0x124/0x1c0 do_syscall_64+0xbb/0xfd0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[...]Allocated by task 109: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7b/0x90 __kmalloc_noprof+0x2c1/0x790 neigh_alloc+0x6af/0x8f0 ___neigh_create+0x63/0xe90 mlxsw_sp_nexthop_neigh_init+0x430/0x7e0 mlxsw_sp_nexthop_type_init+0x212/0x960 mlxsw_sp_nexthop6_group_info_init.constprop.0+0x81f/0x1280 mlxsw_sp_nexthop6_group_get+0x392/0x6a0 mlxsw_sp_fib6_entry_create+0x46a/0xfd0 mlxsw_sp_router_fib6_replace+0x1ed/0x5f0 mlxsw_sp_router_fib6_event_work+0x10a/0x2a0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Freed by task 154: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x43/0x70 kmem_cache_free_bulk.part.0+0x1eb/0x5e0 kvfree_rcu_bulk+0x1f2/0x260 kfree_rcu_work+0x130/0x1b0 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20Last potentially related work creation: kasan_save_stack+0x30/0x50 kasan_record_aux_stack+0x8c/0xa0 kvfree_call_rcu+0x93/0x5b0 mlxsw_sp_router_neigh_event_work+0x67d/0x860 process_one_work+0xd57/0x1390 worker_thread+0x4d6/0xd40 kthread+0x355/0x5b0 ret_from_fork+0x1d4/0x270 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47548 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ethernet: hisilicon: hns: hns_dsaf_misc: fix a possible array overflow in hns_dsaf_ge_srst_by_port()The if statement: if (port >= DSAF_GE_NUM) return;limits the value of port less than DSAF_GE_NUM (i.e., 8).However, if the value of port is 6 or 7, an array overflow could occur: port_rst_off = dsaf_dev->mac_cb[port]->port_rst_off;because the length of dsaf_dev->mac_cb is DSAF_MAX_PORT_NUM (i.e., 6).To fix this possible array overflow, we first check port and if it isgreater than or equal to DSAF_MAX_PORT_NUM, the function returns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49727 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in l2tp_ip6_sendmsgWhen len >= INT_MAX - transhdrlen, ulen = len + transhdrlen will beoverflow. To fix, we can follow what udpv6 does and subtract thetranshdrlen from the max.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49728 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix signed integer overflow in __ip6_append_dataResurrect ubsan overflow checks and ubsan report this warning,fix it by change the variable [length] type to size_t.UBSAN: signed-integer-overflow in net/ipv6/ip6_output.c:1489:192147479552 + 8567 cannot be represented in type 'int'CPU: 0 PID: 253 Comm: err Not tainted 5.16.0+ #1Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0x214/0x230 show_stack+0x30/0x78 dump_stack_lvl+0xf8/0x118 dump_stack+0x18/0x30 ubsan_epilogue+0x18/0x60 handle_overflow+0xd0/0xf0 __ubsan_handle_add_overflow+0x34/0x44 __ip6_append_data.isra.48+0x1598/0x1688 ip6_append_data+0x128/0x260 udpv6_sendmsg+0x680/0xdd0 inet6_sendmsg+0x54/0x90 sock_sendmsg+0x70/0x88 ____sys_sendmsg+0xe8/0x368 ___sys_sendmsg+0x98/0xe0 __sys_sendmmsg+0xf4/0x3b8 __arm64_sys_sendmmsg+0x34/0x48 invoke_syscall+0x64/0x160 el0_svc_common.constprop.4+0x124/0x300 do_el0_svc+0x44/0xc8 el0_svc+0x3c/0x1e8 el0t_64_sync_handler+0x88/0xb0 el0t_64_sync+0x16c/0x170Changes since v1:-Change the variable [length] type to unsigned, as Eric Dumazet suggested.Changes since v2:-Don't change exthdrlen type in ip6_make_skb, as Paolo Abeni suggested.Changes since v3:-Don't change ulen type in udpv6_sendmsg and l2tp_ip6_sendmsg, asJakub Kicinski suggested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50485 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add EXT4_IGET_BAD flag to prevent unexpected bad inodeThere are many places that will get unhappy (and crash) when ext4_iget()returns a bad inode. However, if iget the boot loader inode, allows a badinode to be returned, because the inode may not be initialized. Thismechanism can be used to bypass some checks and cause panic. To solve thisproblem, we add a special iget flag EXT4_IGET_BAD. Only with this flagwe'd be returning bad inode from ext4_iget(), otherwise we always returnthe error code if the inode is bad inode.(suggested by Jan Kara)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50581 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix OOB Read in __hfs_brec_findSyzbot reported a OOB read bug:==================================================================BUG: KASAN: slab-out-of-bounds in hfs_strcmp+0x117/0x190fs/hfs/string.c:84Read of size 1 at addr ffff88807eb62c4e by task kworker/u4:1/11CPU: 1 PID: 11 Comm: kworker/u4:1 Not tainted6.1.0-rc6-syzkaller-00308-g644e9524388a #0Workqueue: writeback wb_workfn (flush-7:0)Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report+0xcd/0x100 mm/kasan/report.c:495 hfs_strcmp+0x117/0x190 fs/hfs/string.c:84 __hfs_brec_find+0x213/0x5c0 fs/hfs/bfind.c:75 hfs_brec_find+0x276/0x520 fs/hfs/bfind.c:138 hfs_write_inode+0x34c/0xb40 fs/hfs/inode.c:462 write_inode fs/fs-writeback.c:1440 [inline]If the input inode of hfs_write_inode() is incorrect:struct inode struct hfs_inode_info struct hfs_cat_key struct hfs_name u8 len # len is greater than HFS_NAMELEN(31) which is themaximum length of an HFS filenameOOB read occurred:hfs_write_inode() hfs_brec_find() __hfs_brec_find() hfs_cat_keycmp() hfs_strcmp() # OOB read occurred due to len is too largeFix this by adding a Check on len in hfs_write_inode() before callinghfs_brec_find().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53462 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in fill_frame_info()Syzbot reports the following uninit-value access problem.=====================================================BUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]BUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 fill_frame_info net/hsr/hsr_forward.c:601 [inline] hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616 hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4889 [inline] netdev_start_xmit include/linux/netdevice.h:4903 [inline] xmit_one net/core/dev.c:3544 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560 __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340 dev_queue_xmit include/linux/netdevice.h:3082 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:644 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] __sys_sendto+0x781/0xa30 net/socket.c:2176 __do_sys_sendto net/socket.c:2188 [inline] __se_sys_sendto net/socket.c:2184 [inline] __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82It is because VLAN not yet supported in hsr driver. Return errorwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53537 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid use-after-free for cached IPU bioxfstest generic/019 reports a bug:kernel BUG at mm/filemap.c:1619!RIP: 0010:folio_end_writeback+0x8a/0x90Call Trace: end_page_writeback+0x1c/0x60 f2fs_write_end_io+0x199/0x420 bio_endio+0x104/0x180 submit_bio_noacct+0xa5/0x510 submit_bio+0x48/0x80 f2fs_submit_write_bio+0x35/0x300 f2fs_submit_merged_ipu_write+0x2a0/0x2b0 f2fs_write_single_data_page+0x838/0x8b0 f2fs_write_cache_pages+0x379/0xa30 f2fs_write_data_pages+0x30c/0x340 do_writepages+0xd8/0x1b0 __writeback_single_inode+0x44/0x370 writeback_sb_inodes+0x233/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x2d0 wb_workfn+0x367/0x4a0 process_one_work+0x21d/0x430 worker_thread+0x4e/0x3c0 kthread+0x103/0x130 ret_from_fork+0x2c/0x50The root cause is: after cp_error is set, f2fs_submit_merged_ipu_write()in f2fs_write_single_data_page() tries to flush IPU bio in cache, howeverf2fs_submit_merged_ipu_write() missed to check validity of @bio parameter,result in submitting random cached bio which belong to other IO context,then it will cause use-after-free issue, fix it by adding additionalvalidity check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53616 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix invalid free of JFS_IP(ipimap)->i_imap in diUnmountsyzbot found an invalid-free in diUnmount:BUG: KASAN: double-free in slab_free mm/slub.c:3661 [inline]BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3674Free of addr ffff88806f410000 by task syz-executor131/3632 CPU: 0 PID: 3632 Comm: syz-executor131 Not tainted 6.1.0-rc7-syzkaller-00012-gca57f02295f1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:284 print_report+0x107/0x1f0 mm/kasan/report.c:395 kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:460 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1724 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1750 slab_free mm/slub.c:3661 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3674 diUnmount+0xef/0x100 fs/jfs/jfs_imap.c:195 jfs_umount+0x108/0x370 fs/jfs/jfs_umount.c:63 jfs_put_super+0x86/0x190 fs/jfs/super.c:194 generic_shutdown_super+0x130/0x310 fs/super.c:492 kill_block_super+0x79/0xd0 fs/super.c:1428 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1186 task_work_run+0x243/0x300 kernel/task_work.c:179 exit_task_work include/linux/task_work.h:38 [inline] do_exit+0x664/0x2070 kernel/exit.c:820 do_group_exit+0x1fd/0x2b0 kernel/exit.c:950 __do_sys_exit_group kernel/exit.c:961 [inline] __se_sys_exit_group kernel/exit.c:959 [inline] __x64_sys_exit_group+0x3b/0x40 kernel/exit.c:959 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd[...]JFS_IP(ipimap)->i_imap is not setting to NULL after free in diUnmount.If jfs_remount() free JFS_IP(ipimap)->i_imap but then failed at diMount().JFS_IP(ipimap)->i_imap will be freed once again.Fix this problem by setting JFS_IP(ipimap)->i_imap to NULL after free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27025 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: null check for nla_nest_startnla_nest_start() may fail and return NULL. Insert a check and set errnobased on other call sites within the same source code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27051 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return valuecpufreq_cpu_get may return NULL. To avoid NULL-dereference check itand return 0 in case of error.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36916 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: avoid out of bounds shiftUBSAN catches undefined behavior in blk-iocost, where sometimesiocg->delay is shifted right by a number that is too large,resulting in undefined behavior on some architectures.[ 186.556576] ------------[ cut here ]------------UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020Call Trace: dump_stack_lvl+0x8f/0xe0 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 iocg_kick_delay+0x30b/0x310 ioc_timer_fn+0x2fb/0x1f80 __run_timer_base+0x1b6/0x250...Avoid that undefined behavior by simply taking the"delay = 0" branch if the shift is too large.I am not sure what the symptoms of an undefined valuedelay will be, but I suspect it could be more than alittle annoying to debug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39472 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa ("xfs: detect and handle invalid iclog size set bymkfs") added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions. Later commit 0c771b99d6c9("xfs: clean up calculation of LR header blocks") cleaned up the logreover buffer calculation, but stoped using the fixed up h_size valueto size the log recovery buffer, which can lead to an out of boundsaccess when the incorrect h_size does not come from the old mkfstool, but a fuzzer.Fix this by open coding xlog_logrec_hblks and taking the fixed h_sizeinto account for this calculation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40927 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Handle TD clearing for multiple streams caseWhen multiple streams are in use, multiple TDs might be in flight whenan endpoint is stopped. We need to issue a Set TR Dequeue Pointer foreach, to ensure everything is reset properly and the caches cleared.Change the logic so that any N>1 TDs found active for different streamsare deferred until after the first one is processed, callingxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() toqueue another command until we are done with all of them. Also changethe error/"should never happen" paths to ensure we at least clear anyaffected TDs, even if we can't issue a command to clear the hardwarecache, and complain loudly with an xhci_warn() if this ever happens.This problem case dates back to commit e9df17eb1408 ("USB: xhci: Correctassumptions about number of rings per endpoint.") early on in the XHCIdriver's life, when stream support was first added.It was then identified but not fixed nor made into a warning in commit674f8438c121 ("xhci: split handling halted endpoints into two steps"),which added a FIXME comment for the problem case (without materiallychanging the behavior as far as I can tell, though the new logic madethe problem more obvious).Then later, in commit 94f339147fc3 ("xhci: Fix failure to give back somecached cancelled URBs."), it was acknowledged again.[Mathias: commit 94f339147fc3 ("xhci: Fix failure to give back some cachedcancelled URBs.") was a targeted regression fix to the previously mentionedpatch. Users reported issues with usb stuck after unmounting/disconnectingUAS devices. This rolled back the TD clearing of multiple streams to itsoriginal state.]Apparently the commit author was aware of the problem (yet still choseto submit it): It was still mentioned as a FIXME, an xhci_dbg() wasadded to log the problem condition, and the remaining issue was mentionedin the commit description. The choice of making the log type xhci_dbg()for what is, at this point, a completely unhandled and known brokencondition is puzzling and unfortunate, as it guarantees that no actualusers would see the log in production, thereby making it nighundebuggable (indeed, even if you turn on DEBUG, the message doesn'treally hint at there being a problem at all).It took me *months* of random xHC crashes to finally find a reliablerepro and be able to do a deep dive debug session, which could all havebeen avoided had this unhandled, broken condition been actually reportedwith a warning, as it should have been as a bug intentionally left inunfixed (never mind that it shouldn't have been left in at all).> Another fix to solve clearing the caches of all stream rings with> cancelled TDs is needed, but not as urgent.3 years after that statement and 14 years after the original bug wasintroduced, I think it's finally time to fix it. And maybe next timelet's not leave bugs unfixed (that are actually worse than the originalbug), and let's actually get people to review kernel commits please.Fixes xHC crashes and IOMMU faults with UAS devices when handlingerrors/faults. Easiest repro is to use `hdparm` to mark an early sector(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.At least in the case of JMicron controllers, the read errors end uphaving to cancel two TDs (for two queued requests to different streams)and the one that didn't get cleared properly ends up faulting the xHCentirely when it tries to access DMA pages that have since been unmapped,referred to by the stale TDs. This normally happens quickly (after twoor three loops). After this fix, I left the `cat` in a loop runningovernight and experienced no xHC failures, with all read errorsrecovered properly. Repro'd and tested on an Apple M1 Mac Mini(dwc3 host).On systems without an IOMMU, this bug would instead silently corruptfreed memory, making this a---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42236 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()Userspace provided string 's' could trivially have the length zero. Leftunchecked this will firstly result in an OOB read in the form`if (str[0 - 1] == '\n') followed closely by an OOB write in the form`str[0 - 1] = '\0'`.There is already a validating check to catch strings that are too long.Let's supply an additional check for invalid strings that are too short.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47697 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write errorEnsure index in rtl2830_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47698 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write errorEnsure index in rtl2832_pid_filter does not exceed 31 to preventout-of-bounds access.dev->filters is a 32-bit value, so set_bit and clear_bit functions shouldonly operate on indices from 0 to 31. If index is 32, it will attempt toaccess a non-existent 33rd bit, leading to out-of-bounds access.Change the boundary check from index > 32 to index >= 32 to resolve thisissue.[hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49894 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in degamma hardware format translationFixes index out of bounds issue in`cm_helper_translate_curve_to_degamma_hw_format` function. The issuecould occur when the index 'i' exceeds the number of transfer functionpoints (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50035 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix ppp_async_encode() illegal accesssyzbot reported an issue in ppp_async_encode() [1]In this case, pppoe_sendmsg() is called with a zero size.Then ppp_async_encode() is called with an empty skb.BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50143 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:udf: fix uninit-value use in udf_get_fileshortadCheck for overflow when computing alen in udf_current_aext to mitigatelater uninit-value use in udf_get_fileshortad KMSAN bug[1].After applying the patch reproducer did not trigger any issue[2].[1] https://syzkaller.appspot.com/bug?extid=8901c4560b7ab5c2f9df[2] https://syzkaller.appspot.com/x/log.txt?x=10242227980000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50148 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bnep: fix wild-memory-access in proto_unregisterThere's issue as follows: KASAN: maybe wild-memory-access in range [0xdead...108-0xdead...10f] CPU: 3 UID: 0 PID: 2805 Comm: rmmod Tainted: G W RIP: 0010:proto_unregister+0xee/0x400 Call Trace: __do_sys_delete_module+0x318/0x580 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAs bnep_init() ignore bnep_sock_init()'s return value, and bnep_sock_init()will cleanup all resource. Then when remove bnep module will callbnep_sock_cleanup() to cleanup sock's resource.To solve above issue just return bnep_sock_init()'s return value inbnep_exit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50150 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmode should keep reference to parentThe altmode device release refers to its parent device, but without keepinga reference to it.When registering the altmode, get a reference to the parent and put it inthe release function.Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issueslike this:[ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)[ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)[ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)[ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)[ 46.612867] ==================================================================[ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129[ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48[ 46.614538][ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535[ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014[ 46.616042] Workqueue: events kobject_delayed_cleanup[ 46.616446] Call Trace:[ 46.616648] [ 46.616820] dump_stack_lvl+0x5b/0x7c[ 46.617112] ? typec_altmode_release+0x38/0x129[ 46.617470] print_report+0x14c/0x49e[ 46.617769] ? rcu_read_unlock_sched+0x56/0x69[ 46.618117] ? __virt_addr_valid+0x19a/0x1ab[ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d[ 46.618807] ? typec_altmode_release+0x38/0x129[ 46.619161] kasan_report+0x8d/0xb4[ 46.619447] ? typec_altmode_release+0x38/0x129[ 46.619809] ? process_scheduled_works+0x3cb/0x85f[ 46.620185] typec_altmode_release+0x38/0x129[ 46.620537] ? process_scheduled_works+0x3cb/0x85f[ 46.620907] device_release+0xaf/0xf2[ 46.621206] kobject_delayed_cleanup+0x13b/0x17a[ 46.621584] process_scheduled_works+0x4f6/0x85f[ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10[ 46.622353] ? hlock_class+0x31/0x9a[ 46.622647] ? lock_acquired+0x361/0x3c3[ 46.622956] ? move_linked_works+0x46/0x7d[ 46.623277] worker_thread+0x1ce/0x291[ 46.623582] ? __kthread_parkme+0xc8/0xdf[ 46.623900] ? __pfx_worker_thread+0x10/0x10[ 46.624236] kthread+0x17e/0x190[ 46.624501] ? kthread+0xfb/0x190[ 46.624756] ? __pfx_kthread+0x10/0x10[ 46.625015] ret_from_fork+0x20/0x40[ 46.625268] ? __pfx_kthread+0x10/0x10[ 46.625532] ret_from_fork_asm+0x1a/0x30[ 46.625805] [ 46.625953][ 46.626056] Allocated by task 678:[ 46.626287] kasan_save_stack+0x24/0x44[ 46.626555] kasan_save_track+0x14/0x2d[ 46.626811] __kasan_kmalloc+0x3f/0x4d[ 46.627049] __kmalloc_noprof+0x1bf/0x1f0[ 46.627362] typec_register_port+0x23/0x491[ 46.627698] cros_typec_probe+0x634/0xbb6[ 46.628026] platform_probe+0x47/0x8c[ 46.628311] really_probe+0x20a/0x47d[ 46.628605] device_driver_attach+0x39/0x72[ 46.628940] bind_store+0x87/0xd7[ 46.629213] kernfs_fop_write_iter+0x1aa/0x218[ 46.629574] vfs_write+0x1d6/0x29b[ 46.629856] ksys_write+0xcd/0x13b[ 46.630128] do_syscall_64+0xd4/0x139[ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 46.630820][ 46.630946] Freed by task 48:[ 46.631182] kasan_save_stack+0x24/0x44[ 46.631493] kasan_save_track+0x14/0x2d[ 46.631799] kasan_save_free_info+0x3f/0x4d[ 46.632144] __kasan_slab_free+0x37/0x45[ 46.632474]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50262 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix out-of-bounds write in trie_get_next_key()trie_get_next_key() allocates a node stack with size trie->max_prefixlen,while it writes (trie->max_prefixlen + 1) nodes to the stack when it hasfull paths from the root to leaves. For example, consider a trie withmax_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ...0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with.prefixlen = 8 make 9 nodes be written on the node stack with size 8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50265 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove()Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove():[ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12[ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry[ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004[...][ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[...][ 57.331328] Call Trace:[ 57.331477] [...][ 57.333511] ? do_user_addr_fault+0x3e5/0x740[ 57.333778] ? exc_page_fault+0x70/0x170[ 57.334016] ? asm_exc_page_fault+0x2b/0x30[ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10[ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0[ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0[ 57.335164] ocfs2_xa_set+0x704/0xcf0[ 57.335381] ? _raw_spin_unlock+0x1a/0x40[ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20[ 57.335915] ? trace_preempt_on+0x1e/0x70[ 57.336153] ? start_this_handle+0x16c/0x500[ 57.336410] ? preempt_count_sub+0x50/0x80[ 57.336656] ? _raw_read_unlock+0x20/0x40[ 57.336906] ? start_this_handle+0x16c/0x500[ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0[ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0[ 57.337706] ? ocfs2_start_trans+0x13d/0x290[ 57.337971] ocfs2_xattr_set+0xb13/0xfb0[ 57.338207] ? dput+0x46/0x1c0[ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30[ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30[ 57.338948] __vfs_removexattr+0x92/0xc0[ 57.339182] __vfs_removexattr_locked+0xd5/0x190[ 57.339456] ? preempt_count_sub+0x50/0x80[ 57.339705] vfs_removexattr+0x5f/0x100[...]Reproducer uses faultinject facility to fail ocfs2_xa_remove() ->ocfs2_xa_value_truncate() with -ENOMEM.In this case the comment mentions that we can return 0 ifocfs2_xa_cleanup_value_truncate() is going to wipe the entryanyway. But the following 'rc' check is wrong and execution flow do'ocfs2_xa_remove_entry(loc);' twice:* 1st: in ocfs2_xa_cleanup_value_truncate();* 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'.Fix this by skipping the 2nd removal of the same entry and makingsyzkaller repro happy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53150 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out of bounds reads when finding clock sourcesThe current USB-audio driver code doesn't check bLength of eachdescriptor at traversing for clock descriptors. That is, when adevice provides a bogus descriptor with a shorter bLength, the drivermight hit out-of-bounds reads.For addressing it, this patch adds sanity checks to the validatorfunctions for the clock descriptor traversal. When the descriptorlength is shorter than expected, it's skipped in the loop.For the clock source and clock multiplier descriptors, we can justcheck bLength against the sizeof() of each descriptor type.OTOH, the clock selector descriptor of UAC2 and UAC3 has an arrayof bNrInPins elements and two more fields at its tail, hence thosehave to be checked in addition to the sizeof() check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53162 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat/qat_4xxx - fix off by one in uof_get_name()The fw_objs[] array has "num_objs" elements so the > needs to be >= toprevent an out of bounds read.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53203 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: fix potential array underflow in ucsi_ccg_sync_control()The "command" variable can be controlled by the user via debugfs. Theworry is that if con_index is zero then "&uc->ucsi->connector[con_index- 1]" would be an array underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53216 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: release svc_expkey/svc_export with rcu_workThe last reference for `cache_head` can be reduced to zero in `c_show`and `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,`svc_export_put` and `expkey_put` will be invoked, leading to twoissues:1. The `svc_export_put` will directly free ex_uuid. However, `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can trigger a use-after-free issue, shown below. ================================================================== BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd] Read of size 1 at addr ff11000010fdc120 by task cat/870 CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_address_description.constprop.0+0x2c/0x3a0 print_report+0xb9/0x280 kasan_report+0xae/0xe0 svc_export_show+0x362/0x430 [nfsd] c_show+0x161/0x390 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Allocated by task 830: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc_node_track_caller_noprof+0x1bc/0x400 kmemdup_noprof+0x22/0x50 svc_export_parse+0x8a9/0xb80 [nfsd] cache_do_downcall+0x71/0xa0 [sunrpc] cache_write_procfs+0x8e/0xd0 [sunrpc] proc_reg_write+0xe1/0x140 vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 868: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kfree+0xf3/0x3e0 svc_export_put+0x87/0xb0 [nfsd] cache_purge+0x17f/0x1f0 [sunrpc] nfsd_destroy_serv+0x226/0x2d0 [nfsd] nfsd_svc+0x125/0x1e0 [nfsd] write_threads+0x16a/0x2a0 [nfsd] nfsctl_transaction_write+0x74/0xa0 [nfsd] vfs_write+0x1a5/0x6d0 ksys_write+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`. However, `svc_export_put`/`expkey_put` will call path_put, which subsequently triggers a sleeping operation due to the following `dput`. ============================= WARNING: suspicious RCU usage 5.10.0-dirty #141 Not tainted ----------------------------- ... Call Trace: dump_stack+0x9a/0xd0 ___might_sleep+0x231/0x240 dput+0x39/0x600 path_put+0x1b/0x30 svc_export_put+0x17/0x80 e_show+0x1c9/0x200 seq_read_iter+0x63f/0x7c0 seq_read+0x226/0x2d0 vfs_read+0x113/0x2c0 ksys_read+0xc9/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Fix these issues by using `rcu_work` to help release`svc_expkey`/`svc_export`. This approach allows for an asynchronouscontext to invoke `path_put` and also facilitates the freeing of`uuid/exp/key` after an RCU grace period.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56662 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctlFix an issue detected by syzbot with KASAN:BUG: KASAN: vmalloc-out-of-bounds in cmd_to_func drivers/acpi/nfit/core.c:416 [inline]BUG: KASAN: vmalloc-out-of-bounds in acpi_nfit_ctl+0x20e8/0x24a0drivers/acpi/nfit/core.c:459The issue occurs in cmd_to_func when the call_pkg->nd_reserved2array is accessed without verifying that call_pkg points to a bufferthat is appropriately sized as a struct nd_cmd_pkg. This can leadto out-of-bounds access and undefined behavior if the buffer does nothave sufficient space.To address this, a check was added in acpi_nfit_ctl() to ensure thatbuf is not NULL and that buf_len is less than sizeof(*call_pkg)before accessing it. This ensures safe access to the members ofcall_pkg, including the nd_reserved2 array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57890 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/uverbs: Prevent integer overflow issueIn the expression "cmd.wqe_size * cmd.wr_count", both variables are u32values that come from the user so the multiplication can lead to integerwrapping. Then we pass the result to uverbs_request_next_ptr() which alsocould potentially wrap. The "cmd.sge_count * sizeof(struct ib_uverbs_sge)"multiplication can also overflow on 32bit systems although it's fine on64bit systems.This patch does two things. First, I've re-arranged the condition inuverbs_request_next_ptr() so that the use controlled variable "len" is onone side of the comparison by itself without any math. Then I've modifiedall the callers to use size_mul() for the multiplications.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58017 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:printk: Fix signed integer overflow when defining LOG_BUF_LEN_MAXShifting 1 << 31 on a 32-bit int causes signed integer overflow, whichleads to undefined behavior. To prevent this, cast 1 to u32 beforeperforming the shift, ensuring well-defined behavior.This change explicitly avoids any potential overflow by ensuring thatthe shift occurs on an unsigned 32-bit integer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-13151 Severity: Moderate CVSS3 score: 6.6

Description: Stack-based buffer overflow in libtasn1 version: v4.20.0. The function fails to validate the size of input data resulting in a buffer overflow in asn1_expend_octet_string.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libtasn1 > 0-0 (version in image is 4.13-150000.4.11.1).

CVE-2025-21711 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:net/rose: prevent integer overflows in rose_setsockopt()In case of possible unpredictably large arguments passed torose_setsockopt() and multiplied by extra values on top of that,integer overflows may occur.Do the safest minimum and fix these issues by checking thecontents of 'opt' and returning -EINVAL if they are too large. Also,switch to unsigned int and remove useless check for negative 'opt'in ROSE_IDLE case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38003 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add missing rcu read protection for procfs contentWhen the procfs content is generated for a bcm_op which is in the processto be removed the procfs output might show unreliable data (UAF).As the removal of bcm_op's is already implemented with rcu handling thispatch adds the missing rcu_read_lock() and makes sure the list entriesare properly removed under rcu protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38161 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix error flow upon firmware failure for RQ destructionUpon RQ destruction if the firmware command fails which is thelast resource to be destroyed some SW resources were already cleanedregardless of the failure.Now properly rollback the object to its original state upon such failure.In order to avoid a use-after free in case someone tries to destroy theobject again, which results in the following kernel trace:refcount_t: underflow; use-after-free.WARNING: CPU: 0 PID: 37589 at lib/refcount.c:28 refcount_warn_saturate+0xf4/0x148Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) rfkill mlx5_core(OE) mlxdevm(OE) ib_uverbs(OE) ib_core(OE) psample mlxfw(OE) mlx_compat(OE) macsec tls pci_hyperv_intf sunrpc vfat fat virtio_net net_failover failover fuse loop nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce virtio_console virtio_gpu virtio_blk virtio_dma_buf virtio_mmio dm_mirror dm_region_hash dm_log dm_mod xpmem(OE)CPU: 0 UID: 0 PID: 37589 Comm: python3 Kdump: loaded Tainted: G OE ------- --- 6.12.0-54.el10.aarch64 #1Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULEHardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : refcount_warn_saturate+0xf4/0x148lr : refcount_warn_saturate+0xf4/0x148sp : ffff80008b81b7e0x29: ffff80008b81b7e0 x28: ffff000133d51600 x27: 0000000000000001x26: 0000000000000000 x25: 00000000ffffffea x24: ffff00010ae80f00x23: ffff00010ae80f80 x22: ffff0000c66e5d08 x21: 0000000000000000x20: ffff0000c66e0000 x19: ffff00010ae80340 x18: 0000000000000006x17: 0000000000000000 x16: 0000000000000020 x15: ffff80008b81b37fx14: 0000000000000000 x13: 2e656572662d7265 x12: ffff80008283ef78x11: ffff80008257efd0 x10: ffff80008283efd0 x9 : ffff80008021ed90x8 : 0000000000000001 x7 : 00000000000bffe8 x6 : c0000000ffff7fffx5 : ffff0001fb8e3408 x4 : 0000000000000000 x3 : ffff800179993000x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000133d51600Call trace: refcount_warn_saturate+0xf4/0x148 mlx5_core_put_rsc+0x88/0xa0 [mlx5_ib] mlx5_core_destroy_rq_tracked+0x64/0x98 [mlx5_ib] mlx5_ib_destroy_wq+0x34/0x80 [mlx5_ib] ib_destroy_wq_user+0x30/0xc0 [ib_core] uverbs_free_wq+0x28/0x58 [ib_uverbs] destroy_hw_idr_uobject+0x34/0x78 [ib_uverbs] uverbs_destroy_uobject+0x48/0x240 [ib_uverbs] __uverbs_cleanup_ufile+0xd4/0x1a8 [ib_uverbs] uverbs_destroy_ufile_hw+0x48/0x120 [ib_uverbs] ib_uverbs_close+0x2c/0x100 [ib_uverbs] __fput+0xd8/0x2f0 __fput_sync+0x50/0x70 __arm64_sys_close+0x40/0x90 invoke_syscall.constprop.0+0x74/0xd0 do_el0_svc+0x48/0xe8 el0_svc+0x44/0x1d0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x1a4/0x1a8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38162 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: prevent overflow in lookup table allocationWhen calculating the lookup table size, ensure the followingmultiplication does not overflow:- desc->field_len[] maximum value is U8_MAX multiplied by NFT_PIPAPO_GROUPS_PER_BYTE(f) that can be 2, worst case.- NFT_PIPAPO_BUCKETS(f->bb) is 2^8, worst case.- sizeof(unsigned long), from sizeof(*f->lt), lt in struct nft_pipapo_field.Then, use check_mul_overflow() to multiply by bucket size and then usecheck_add_overflow() to the alignment for avx2 (if needed). Finally, addlt_size_check_overflow() helper and use it to consolidate this.While at it, replace leftover allocation using the GFP_KERNEL toGFP_KERNEL_ACCOUNT for consistency, in pipapo_resize().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38166 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix ktls panic with sockmap[ 2172.936997] ------------[ cut here ]------------[ 2172.936999] kernel BUG at lib/iov_iter.c:629!......[ 2172.944996] PKRU: 55555554[ 2172.945155] Call Trace:[ 2172.945299] [ 2172.945428] ? die+0x36/0x90[ 2172.945601] ? do_trap+0xdd/0x100[ 2172.945795] ? iov_iter_revert+0x178/0x180[ 2172.946031] ? iov_iter_revert+0x178/0x180[ 2172.946267] ? do_error_trap+0x7d/0x110[ 2172.946499] ? iov_iter_revert+0x178/0x180[ 2172.946736] ? exc_invalid_op+0x50/0x70[ 2172.946961] ? iov_iter_revert+0x178/0x180[ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20[ 2172.947446] ? iov_iter_revert+0x178/0x180[ 2172.947683] ? iov_iter_revert+0x5c/0x180[ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840[ 2172.948206] tls_sw_sendmsg+0x52/0x80[ 2172.948420] ? inet_sendmsg+0x1f/0x70[ 2172.948634] __sys_sendto+0x1cd/0x200[ 2172.948848] ? find_held_lock+0x2b/0x80[ 2172.949072] ? syscall_trace_enter+0x140/0x270[ 2172.949330] ? __lock_release.isra.0+0x5e/0x170[ 2172.949595] ? find_held_lock+0x2b/0x80[ 2172.949817] ? syscall_trace_enter+0x140/0x270[ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190[ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0[ 2172.951036] __x64_sys_sendto+0x24/0x30[ 2172.951382] do_syscall_64+0x90/0x170......After calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,e.g., when the BPF program executes bpf_msg_push_data().If the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,it will return -ENOSPC and attempt to roll back to the non-zero copylogic. However, during rollback, msg->msg_iter is reset, but sincemsg_pl->sg.size has been increased, subsequent executions will exceed theactual size of msg_iter.'''iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);'''The changes in this commit are based on the following considerations:1. When cork_bytes is set, rolling back to non-zero copy logic ispointless and can directly go to zero-copy logic.2. We can not calculate the correct number of bytes to revert msg_iter.Assume the original data is "abcdefgh" (8 bytes), and after 3 pushesby the BPF program, it becomes 11-byte data: "abc?de?fgh?".Then, we set cork_bytes to 6, which means the first 6 bytes have beenprocessed, and the remaining 5 bytes "?fgh?" will be cached until thelength meets the cork_bytes requirement.However, some data in "?fgh?" is not within 'sg->msg_iter'(but in msg_pl instead), especially the data "?" we pushed.So it doesn't seem as simple as just reverting through an offset ofmsg_iter.3. For non-TLS sockets in tcp_bpf_sendmsg, when a "cork" situation occurs,the user-space send() doesn't return an error, and the returned length isthe same as the input length parameter, even if some data is cached.Additionally, I saw that the current non-zero-copy logic for handlingcorking is written as:'''line 1177else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end;'''So it's ok to just return 'copied' without error when a "cork" situationoccurs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38395 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: gpio: Fix the out-of-bounds access to drvdata::gpiodsdrvdata::gpiods is supposed to hold an array of 'gpio_desc' pointers. Butthe memory is allocated for only one pointer. This will lead toout-of-bounds access later in the code if 'config::ngpios' is > 1. Sofix the code to allocate enough memory to hold 'config::ngpios' of GPIOdescriptors.While at it, also move the check for memory allocation failure to be belowthe allocation to make it more readable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38408 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/irq_sim: Initialize work context pointers properlyInitialize `ops` member's pointers properly by using kzalloc() instead ofkmalloc() when allocating the simulation work context. Otherwise thepointers contain random content leading to invalid dereferencing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38449 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gem: Acquire references on GEM handles for framebuffersA GEM handle can be released while the GEM buffer object is attachedto a DRM framebuffer. This leads to the release of the dma-buf backingthe buffer object, if any. [1] Trying to use the framebuffer in furthermode-setting operations leads to a segmentation fault. Most easilyhappens with driver that use shadow planes for vmap-ing the dma-bufduring a page flip. An example is shown below.[ 156.791968] ------------[ cut here ]------------[ 156.796830] WARNING: CPU: 2 PID: 2255 at drivers/dma-buf/dma-buf.c:1527 dma_buf_vmap+0x224/0x430[...][ 156.942028] RIP: 0010:dma_buf_vmap+0x224/0x430[ 157.043420] Call Trace:[ 157.045898] [ 157.048030] ? show_trace_log_lvl+0x1af/0x2c0[ 157.052436] ? show_trace_log_lvl+0x1af/0x2c0[ 157.056836] ? show_trace_log_lvl+0x1af/0x2c0[ 157.061253] ? drm_gem_shmem_vmap+0x74/0x710[ 157.065567] ? dma_buf_vmap+0x224/0x430[ 157.069446] ? __warn.cold+0x58/0xe4[ 157.073061] ? dma_buf_vmap+0x224/0x430[ 157.077111] ? report_bug+0x1dd/0x390[ 157.080842] ? handle_bug+0x5e/0xa0[ 157.084389] ? exc_invalid_op+0x14/0x50[ 157.088291] ? asm_exc_invalid_op+0x16/0x20[ 157.092548] ? dma_buf_vmap+0x224/0x430[ 157.096663] ? dma_resv_get_singleton+0x6d/0x230[ 157.101341] ? __pfx_dma_buf_vmap+0x10/0x10[ 157.105588] ? __pfx_dma_resv_get_singleton+0x10/0x10[ 157.110697] drm_gem_shmem_vmap+0x74/0x710[ 157.114866] drm_gem_vmap+0xa9/0x1b0[ 157.118763] drm_gem_vmap_unlocked+0x46/0xa0[ 157.123086] drm_gem_fb_vmap+0xab/0x300[ 157.126979] drm_atomic_helper_prepare_planes.part.0+0x487/0xb10[ 157.133032] ? lockdep_init_map_type+0x19d/0x880[ 157.137701] drm_atomic_helper_commit+0x13d/0x2e0[ 157.142671] ? drm_atomic_nonblocking_commit+0xa0/0x180[ 157.147988] drm_mode_atomic_ioctl+0x766/0xe40[...][ 157.346424] ---[ end trace 0000000000000000 ]---Acquiring GEM handles for the framebuffer's GEM buffer objects preventsthis from happening. The framebuffer's cleanup later puts the handlereferences.Commit 1a148af06000 ("drm/gem-shmem: Use dma_buf from GEM objectinstance") triggers the segmentation fault easily by using the dma-buffield more widely. The underlying issue with reference counting hasbeen present before.v2:- acquire the handle instead of the BO (Christian)- fix comment style (Christian)- drop the Fixes tag (Christian)- rename err_ gotos- add missing Link tag

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38455 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Reject SEV{-ES} intra host migration if vCPU creation is in-flightReject migration of SEV{-ES} state if either the source or destination VMis actively creating a vCPU, i.e. if kvm_vm_ioctl_create_vcpu() is in thesection between incrementing created_vcpus and online_vcpus. The bulk ofvCPU creation runs _outside_ of kvm->lock to allow creating multiple vCPUsin parallel, and so sev_info.es_active can get toggled from false=>true inthe destination VM after (or during) svm_vcpu_create(), resulting in anSEV{-ES} VM effectively having a non-SEV{-ES} vCPU.The issue manifests most visibly as a crash when trying to free a vCPU'sNULL VMSA page in an SEV-ES VM, but any number of things can go wrong. BUG: unable to handle page fault for address: ffffebde00000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP KASAN NOPTI CPU: 227 UID: 0 PID: 64063 Comm: syz.5.60023 Tainted: G U O 6.15.0-smp-DEV #2 NONE Tainted: [U]=USER, [O]=OOT_MODULE Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 12.52.0-0 10/28/2024 RIP: 0010:constant_test_bit arch/x86/include/asm/bitops.h:206 [inline] RIP: 0010:arch_test_bit arch/x86/include/asm/bitops.h:238 [inline] RIP: 0010:_test_bit include/asm-generic/bitops/instrumented-non-atomic.h:142 [inline] RIP: 0010:PageHead include/linux/page-flags.h:866 [inline] RIP: 0010:___free_pages+0x3e/0x120 mm/page_alloc.c:5067 Code: <49> f7 06 40 00 00 00 75 05 45 31 ff eb 0c 66 90 4c 89 f0 4c 39 f0 RSP: 0018:ffff8984551978d0 EFLAGS: 00010246 RAX: 0000777f80000001 RBX: 0000000000000000 RCX: ffffffff918aeb98 RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffebde00000000 RBP: 0000000000000000 R08: ffffebde00000007 R09: 1ffffd7bc0000000 R10: dffffc0000000000 R11: fffff97bc0000001 R12: dffffc0000000000 R13: ffff8983e19751a8 R14: ffffebde00000000 R15: 1ffffd7bc0000000 FS: 0000000000000000(0000) GS:ffff89ee661d3000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffebde00000000 CR3: 000000793ceaa000 CR4: 0000000000350ef0 DR0: 0000000000000000 DR1: 0000000000000b5f DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: sev_free_vcpu+0x413/0x630 arch/x86/kvm/svm/sev.c:3169 svm_vcpu_free+0x13a/0x2a0 arch/x86/kvm/svm/svm.c:1515 kvm_arch_vcpu_destroy+0x6a/0x1d0 arch/x86/kvm/x86.c:12396 kvm_vcpu_destroy virt/kvm/kvm_main.c:470 [inline] kvm_destroy_vcpus+0xd1/0x300 virt/kvm/kvm_main.c:490 kvm_arch_destroy_vm+0x636/0x820 arch/x86/kvm/x86.c:12895 kvm_put_kvm+0xb8e/0xfb0 virt/kvm/kvm_main.c:1310 kvm_vm_release+0x48/0x60 virt/kvm/kvm_main.c:1369 __fput+0x3e4/0x9e0 fs/file_table.c:465 task_work_run+0x1a9/0x220 kernel/task_work.c:227 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0x7f0/0x25b0 kernel/exit.c:953 do_group_exit+0x203/0x2d0 kernel/exit.c:1102 get_signal+0x1357/0x1480 kernel/signal.c:3034 arch_do_signal_or_restart+0x40/0x690 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x67/0xb0 kernel/entry/common.c:218 do_syscall_64+0x7c/0x150 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f87a898e969 Modules linked in: gq(O) gsmi: Log Shutdown Reason 0x03 CR2: ffffebde00000000 ---[ end trace 0000000000000000 ]---Deliberately don't check for a NULL VMSA when freeing the vCPU, as crashingthe host is likely desirable due to the VMSA being consumed by hardware.E.g. if KVM manages to allow VMRUN on the vCPU, hardware may read/write abogus VMSA page. Accessing P---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38466 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:perf: Revert to requiring CAP_SYS_ADMIN for uprobesJann reports that uprobes can be used destructively when used in themiddle of an instruction. The kernel only verifies there is a validinstruction at the requested offset, but due to variable instructionlength cannot determine if this is an instruction as seen by theintended execution stream.Additionally, Mark Rutland notes that on architectures that mix datain the text segment (like arm64), a similar things can be done if thedata word is 'mistaken' for an instruction.As such, require CAP_SYS_ADMIN for uprobes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38556 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Harden s32ton() against conversion to 0 bitsTesting by the syzbot fuzzer showed that the HID core gets ashift-out-of-bounds exception when it tries to convert a 32-bitquantity to a 0-bit quantity. Ideally this should never occur, butthere are buggy devices and some might have a report field with sizeset to zero; we shouldn't reject the report or the device just becauseof that.Instead, harden the s32ton() routine so that it returns a reasonableresult instead of crashing when it is called with the number of bitsset to 0 -- the same as what snto32() does.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38574 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:pptp: ensure minimal skb length in pptp_xmit()Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb dataon ppp_sync_txmung") fixed ppp_sync_txmunge()We need a similar fix in pptp_xmit(), otherwise we mightread uninit data as reported by syzbot.BUG: KMSAN: uninit-value in pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptp_xmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2290 [inline] ppp_input+0x1d6/0xe60 drivers/net/ppp/ppp_generic.c:2314 pppoe_rcv_core+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 pppoe_sendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x893/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmmsg+0x2d9/0x7c0 net/socket.c:2709

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38604 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Kill URBs before clearing tx status queueIn rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearingb_tx_status.queue. This change prevents callbacks from using already freedskb due to anchor was not killed before freeing such skb. BUG: kernel NULL pointer dereference, address: 0000000000000080 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211] Call Trace: rtl8187_tx_cb+0x116/0x150 [rtl8187] __usb_hcd_giveback_urb+0x9d/0x120 usb_giveback_urb_bh+0xbb/0x140 process_one_work+0x19b/0x3c0 bh_worker+0x1a7/0x210 tasklet_action+0x10/0x30 handle_softirqs+0xf0/0x340 __irq_exit_rcu+0xcd/0xf0 common_interrupt+0x85/0xa0 Tested on RTL8187BvE device.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39952 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: avoid buffer overflow in WID string configurationFix the following copy overflow warning identified by Smatch checker. drivers/net/wireless/microchip/wilc1000/wlan_cfg.c:184 wilc_wlan_parse_response_frame() error: '__memcpy()' 'cfg->s[i]->str' copy overflow (512 vs 65537)This patch introduces size check before accessing the memory buffer.The checks are base on the WID type of received data from the firmware.For WID string configuration, the size limit is determined by individualelement size in 'struct wilc_cfg_str_vals' that is maintained in 'len' fieldof 'struct wilc_cfg_str'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39965 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: xfrm_alloc_spi shouldn't use 0 as SPIx->id.spi == 0 means "no SPI assigned", but since commit94f39804d891 ("xfrm: Duplicate SPI Handling"), we now create statesand add them to the byspi list with this value.__xfrm_state_delete doesn't remove those states from the byspi list,since they shouldn't be there, and this shows up as a UAF the nexttime we go through the byspi list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39971 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix idx validation in config queues msgEnsure idx is within range of active/initialized TCs when iterating overvf->ch[idx] in i40e_vc_config_queues_msg().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40219 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/IOV: Add PCI rescan-remove locking when enabling/disabling SR-IOVBefore disabling SR-IOV via config space accesses to the parent PF,sriov_disable() first removes the PCI devices representing the VFs.Since commit 9d16947b7583 ("PCI: Add global pci_lock_rescan_remove()")such removal operations are serialized against concurrent remove andrescan using the pci_rescan_remove_lock. No such locking was ever addedin sriov_disable() however. In particular when commit 18f9e9d150fc("PCI/IOV: Factor out sriov_add_vfs()") factored out the PCI deviceremoval into sriov_del_vfs() there was still no locking around thepci_iov_remove_virtfn() calls.On s390 the lack of serialization in sriov_disable() may cause doubleremove and list corruption with the below (amended) trace being observed: PSW: 0704c00180000000 0000000c914e4b38 (klist_put+56) GPRS: 000003800313fb48 0000000000000000 0000000100000001 0000000000000001 00000000f9b520a8 0000000000000000 0000000000002fbd 00000000f4cc9480 0000000000000001 0000000000000000 0000000000000000 0000000180692828 00000000818e8000 000003800313fe2c 000003800313fb20 000003800313fad8 #0 [3800313fb20] device_del at c9158ad5c #1 [3800313fb88] pci_remove_bus_device at c915105ba #2 [3800313fbd0] pci_iov_remove_virtfn at c9152f198 #3 [3800313fc28] zpci_iov_remove_virtfn at c90fb67c0 #4 [3800313fc60] zpci_bus_remove_device at c90fb6104 #5 [3800313fca0] __zpci_event_availability at c90fb3dca #6 [3800313fd08] chsc_process_sei_nt0 at c918fe4a2 #7 [3800313fd60] crw_collect_info at c91905822 #8 [3800313fe10] kthread at c90feb390 #9 [3800313fe68] __ret_from_fork at c90f6aa64 #10 [3800313fe98] ret_from_fork at c9194f3f2.This is because in addition to sriov_disable() removing the VFs, theplatform also generates hot-unplug events for the VFs. This being thereverse operation to the hotplug events generated by sriov_enable() andhandled via pdev->no_vf_scan. And while the event processing takespci_rescan_remove_lock and checks whether the struct pci_dev still exists,the lack of synchronization makes this checking racy.Other races may also be possible of course though given that this lack oflocking persisted so long observable races seem very rare. Even on s390 thelist corruption was only observed with certain devices since the platformevents are only triggered by config accesses after the removal, so as longas the removal finished synchronously they would not race. Either way thelocking is missing so fix this by adding it to the sriov_del_vfs() helper.Just like PCI rescan-remove, locking is also missing in sriov_add_vfs()including for the error case where pci_stop_and_remove_bus_device() iscalled without the PCI rescan-remove lock being held. Even in the non-errorcase, adding new PCI devices and buses should be serialized via the PCIrescan-remove lock. Add the necessary locking.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40283 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: reorder cleanup in btusb_disconnect to avoid UAFThere is a KASAN: slab-use-after-free read in btusb_disconnect().Calling "usb_driver_release_interface(&btusb_driver, data->intf)" willfree the btusb data associated with the interface. The same data isthen used later in the function, hence the UAF.Fix by moving the accesses to btusb data to before the data is free'd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-46836 Severity: Moderate CVSS3 score: 6.6

Description: net-tools is a collection of programs that form the base set of the NET-3 networking distribution for the Linux operating system. Inn versions up to and including 2.10, the Linux network utilities (like ifconfig) from the net-tools package do not properly validate the structure of /proc files when showing interfaces. `get_name()` in `interface.c` copies interface labels from `/proc/net/dev` into a fixed 16-byte stack buffer without bounds checking, leading to possible arbitrary code execution or crash. The known attack path does not require privilege but also does not provide privilege escalation in this scenario. A patch is available and expected to be part of version 2.20.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
net-tools > 0-0 (version in image is 2.0+git20170221.479bb4a-150000.5.13.1).

CVE-2025-67499 Severity: Moderate CVSS3 score: 6.6

Description: The CNI portmap plugin allows containers to emulate opening a host port, forwarding that traffic to the container. Versions 1.6.0 through 1.8.0 inadvertently forward all traffic with the same destination port as the host port when the portmap plugin is configured with the nftables backend, thus ignoring the destination IP. This includes traffic not intended for the node itself, i.e. traffic to containers hosted on the node. Containers that request HostPort forwarding can intercept all traffic destined for that port. This requires that the portmap plugin be explicitly configured to use the nftables backend. This issue is fixed in version 1.9.0. To workaround, configure the portmap plugin to use the iptables backend. It does not have this vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-68340 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:team: Move team device type change at the end of team_port_addAttempting to add a port device that is already up will expectedly fail,but not before modifying the team device header_ops.In the case of the syzbot reproducer the gre0 device isalready in state UP when it attempts to add it as aport device of team0, this fails but before thatheader_ops->create of team0 is changed from eth_header to ipgre_headerin the call to team_dev_type_check_change.Later when we end up in ipgre_header() struct ip_tunnel* points to nonsenseas the private data of the device still holds a struct team.Example sequence of iproute2 commands to reproduce the hang/BUG():ip link add dev team0 type teamip link add dev gre0 type greip link set dev gre0 upip link set dev gre0 master team0ip link set dev team0 upping -I team0 1.1.1.1Move team_dev_type_check_change down where all other checks have passedas it changes the dev type with no way to restore it in caseone of the checks that follow it fail.Also make sure to preserve the origial mtu assignment: - If port_dev is not the same type as dev, dev takes mtu from port_dev - If port_dev is the same type as dev, port_dev takes mtu from devThis is done by adding a conditional before the call to dev_set_mtuto prevent it from assigning port_dev->mtu = dev->mtu and insteadletting team_dev_type_check_change assign dev->mtu = port_dev->mtu.The conditional is needed because the patch moves the call toteam_dev_type_check_change past dev_set_mtu.Testing: - team device driver in-tree selftests - Add/remove various devices as slaves of team device - syzbot

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68750 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: potential integer overflow in usbg_make_tpg()The variable tpgt in usbg_make_tpg() is defined as unsigned long and isassigned to tpgt->tport_tpgt, which is defined as u16. This may cause aninteger overflow when tpgt is greater than USHRT_MAX (65535). Ihaven't tried to trigger it myself, but it is possible to trigger itby calling usbg_make_tpg() with a large value for tpgt.I modified the type of tpgt to match tpgt->tport_tpgt and adjusted therelevant code accordingly.This patch is similar to commit 59c816c1f24d ("vhost/scsi: potentialmemory corruption").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68777 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:Input: ti_am335x_tsc - fix off-by-one error in wire_order validationThe current validation 'wire_order[i] > ARRAY_SIZE(config_pins)' allowswire_order[i] to equal ARRAY_SIZE(config_pins), which causes out-of-boundsaccess when used as index in 'config_pins[wire_order[i]]'.Since config_pins has 4 elements (indices 0-3), the valid range forwire_order should be 0-3. Fix the off-by-one error by using >= insteadof > in the validation check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71113 Severity: Moderate CVSS3 score: 6.6

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - zero initialize memory allocated via sock_kmallocSeveral crypto user API contexts and requests allocated withsock_kmalloc() were left uninitialized, relying on callers toset fields explicitly. This resulted in the use of uninitializeddata in certain error paths or when new fields are added in thefuture.The ACVP patches also contain two user-space interface files:algif_kpp.c and algif_akcipher.c. These too rely on properinitialization of their context structures.A particular issue has been observed with the newly added'inflight' variable introduced in af_alg_ctx by commit: 67b164a871af ("crypto: af_alg - Disallow multiple in-flight AIO requests")Because the context is not memset to zero after allocation,the inflight variable has contained garbage values. As a result,af_alg_alloc_areq() has incorrectly returned -EBUSY randomly whenthe garbage value was interpreted as true: https://github.com/gregkh/linux/blame/master/crypto/af_alg.c#L1209The check directly tests ctx->inflight without explicitlycomparing against true/false. Since inflight is only ever set totrue or false later, an uninitialized value has triggered-EBUSY failures. Zero-initializing memory allocated withsock_kmalloc() ensures inflight and other fields start in a knownstate, removing random issues caused by uninitialized data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8058 Severity: Moderate CVSS3 score: 6.6

Description: The regcomp function in the GNU C library version from 2.4 to 2.41 is subject to a double free if some previous allocation fails. It can be accomplished either by a malloc failure or by using an interposed malloc that injects random malloc failures. The double free can allow buffer manipulation depending of how the regex is constructed. This issue affects all architectures and ABIs supported by the GNU C library.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc > 0-0 (version in image is 2.31-150300.95.1).

CVE-2025-27466 Severity: Important CVSS3 score: 6.5

Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs < 4.16.7_04-150400.4.75.1 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2025-58142 Severity: Important CVSS3 score: 6.5

Description: [This CNA information record relates to multiple CVEs; thetext explains which aspects/vulnerabilities correspond to which CVE.]There are multiple issues related to the handling and accessing of guestmemory pages in the viridian code: 1. A NULL pointer dereference in the updating of the reference TSC area. This is CVE-2025-27466. 2. A NULL pointer dereference by assuming the SIM page is mapped when a synthetic timer message has to be delivered. This is CVE-2025-58142. 3. A race in the mapping of the reference TSC page, where a guest can get Xen to free a page while still present in the guest physical to machine (p2m) page tables. This is CVE-2025-58143.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs < 4.16.7_04-150400.4.75.1 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2021-47517 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: do not perform operations on net devices being unregisteredThere is a short period between a net device starts to be unregisteredand when it is actually gone. In that time frame ethtool operationscould still be performed, which might end up in unwanted or undefinedbehaviours[1].Do not allow ethtool operations after a net device starts itsunregistration. This patch targets the netlink part as the ioctl oneisn't affected: the reference to the net device is taken and theoperation is executed within an rtnl lock section and the net devicewon't be found after unregister.[1] For example adding Tx queues after unregister ends up in NULL pointer exceptions and UaFs, such as: BUG: KASAN: use-after-free in kobject_get+0x14/0x90 Read of size 1 at addr ffff88801961248c by task ethtool/755 CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014 Call Trace: dump_stack_lvl+0x57/0x72 print_address_description.constprop.0+0x1f/0x140 kasan_report.cold+0x7f/0x11b kobject_get+0x14/0x90 kobject_add_internal+0x3d1/0x450 kobject_init_and_add+0xba/0xf0 netdev_queue_update_kobjects+0xcf/0x200 netif_set_real_num_tx_queues+0xb4/0x310 veth_set_channels+0x1c3/0x550 ethnl_set_channels+0x524/0x610

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50780 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix UAF issue in nfqnl_nf_hook_drop() when ops_init() failedWhen the ops_init() interface is invoked to initialize the net, butops->init() fails, data is released. However, the ptr pointer innet->gen is invalid. In this case, when nfqnl_nf_hook_drop() is invokedto release the net, invalid address access occurs.The process is as follows:setup_net() ops_init() data = kzalloc(...) ---> alloc "data" net_assign_generic() ---> assign "date" to ptr in net->gen ... ops->init() ---> failed ... kfree(data); ---> ptr in net->gen is invalid ... ops_exit_list() ... nfqnl_nf_hook_drop() *q = nfnl_queue_pernet(net) ---> q is invalidThe following is the Call Trace information:BUG: KASAN: use-after-free in nfqnl_nf_hook_drop+0x264/0x280Read of size 8 at addr ffff88810396b240 by task ip/15855Call Trace:dump_stack_lvl+0x8e/0xd1print_report+0x155/0x454kasan_report+0xba/0x1f0nfqnl_nf_hook_drop+0x264/0x280nf_queue_nf_hook_drop+0x8b/0x1b0__nf_unregister_net_hook+0x1ae/0x5a0nf_unregister_net_hooks+0xde/0x130ops_exit_list+0xb0/0x170setup_net+0x7ac/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Allocated by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30__kasan_kmalloc+0xa1/0xb0__kmalloc+0x49/0xb0ops_init+0xe7/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0Freed by task 15855:kasan_save_stack+0x1e/0x40kasan_set_track+0x21/0x30kasan_save_free_info+0x2a/0x40____kasan_slab_free+0x155/0x1b0slab_free_freelist_hook+0x11b/0x220__kmem_cache_free+0xa4/0x360ops_init+0xb9/0x410setup_net+0x5aa/0xbd0copy_net_ns+0x2e6/0x6b0create_new_namespaces+0x382/0xa50unshare_nsproxy_namespaces+0xa6/0x1c0ksys_unshare+0x3a4/0x7e0__x64_sys_unshare+0x2d/0x40do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-46841 Severity: Moderate CVSS3 score: 6.5

Description: Recent x86 CPUs offer functionality named Control-flow EnforcementTechnology (CET). A sub-feature of this are Shadow Stacks (CET-SS).CET-SS is a hardware feature designed to protect against Return OrientedProgramming attacks. When enabled, traditional stacks holding both dataand return addresses are accompanied by so called "shadow stacks",holding little more than return addresses. Shadow stacks aren'twritable by normal instructions, and upon function returns theircontents are used to check for possible manipulation of a return addresscoming from the traditional stack.In particular certain memory accesses need intercepting by Xen. Invarious cases the necessary emulation involves kind of replaying ofthe instruction. Such replaying typically involves filling and theninvoking of a stub. Such a replayed instruction may raise anexceptions, which is expected and dealt with accordingly.Unfortunately the interaction of both of the above wasn't right:Recovery involves removal of a call frame from the (traditional) stack.The counterpart of this operation for the shadow stack was missing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2023-46842 Severity: Moderate CVSS3 score: 6.5

Description: Unlike 32-bit PV guests, HVM guests may switch freely between 64-bit andother modes. This in particular means that they may set registers usedto pass 32-bit-mode hypercall arguments to values outside of the range32-bit code would be able to set them to.When processing of hypercalls takes a considerable amount of time,the hypervisor may choose to invoke a hypercall continuation. Doing soinvolves putting (perhaps updated) hypercall arguments in respectiveregisters. For guests not running in 64-bit mode this further involvesa certain amount of translation of the values.Unfortunately internal sanity checking of these translated valuesassumes high halves of registers to always be clear when invoking ahypercall. When this is found not to be the case, it triggers aconsistency check in the hypervisor and causes a crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2023-51385 Severity: Moderate CVSS3 score: 6.5

Description: In ssh in OpenSSH before 9.6, OS command injection might occur if a user name or host name has shell metacharacters, and this name is referenced by an expansion token in certain situations. For example, an untrusted Git repository can have a submodule with shell metacharacters in a user name or host name.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
openssh > 0-0 (version in image is 8.4p1-150300.3.49.1).

CVE-2023-52434 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential OOBs in smb2_parse_contexts()Validate offsets and lengths before dereferencing create contexts insmb2_parse_contexts().This fixes following oops when accessing invalid create contexts fromserver: BUG: unable to handle page fault for address: ffff8881178d8cc3 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 4a01067 P4D 4a01067 PUD 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs] Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00 00 00 8b 45 00 85 c0 74 61 41 29 c5 48 01 c5 41 83 fd 0f 76 55 <0f> b7 7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00 RSP: 0018:ffffc900007939e0 EFLAGS: 00010216 RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90 RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000 RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000 R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000 R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22 FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x181/0x480 ? search_module_extables+0x19/0x60 ? srso_alias_return_thunk+0x5/0xfbef5 ? exc_page_fault+0x1b6/0x1c0 ? asm_exc_page_fault+0x26/0x30 ? smb2_parse_contexts+0xa0/0x3a0 [cifs] SMB2_open+0x38d/0x5f0 [cifs] ? smb2_is_path_accessible+0x138/0x260 [cifs] smb2_is_path_accessible+0x138/0x260 [cifs] cifs_is_path_remote+0x8d/0x230 [cifs] cifs_mount+0x7e/0x350 [cifs] cifs_smb3_do_mount+0x128/0x780 [cifs] smb3_get_tree+0xd9/0x290 [cifs] vfs_get_tree+0x2c/0x100 ? capable+0x37/0x70 path_mount+0x2d7/0xb80 ? srso_alias_return_thunk+0x5/0xfbef5 ? _raw_spin_unlock_irqrestore+0x44/0x60 __x64_sys_mount+0x11a/0x150 do_syscall_64+0x47/0xf0 entry_SYSCALL_64_after_hwframe+0x6f/0x77 RIP: 0033:0x7f8737657b1e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53296 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: check send stream number after wait_for_sndbufThis patch fixes a corner case where the asoc out stream count may changeafter wait_for_sndbuf.When the main thread in the client starts a connection, if its out streamcount is set to N while the in stream count in the server is set to N - 2,another thread in the client keeps sending the msgs with stream numberN - 1, and waits for sndbuf before processing INIT_ACK.However, after processing INIT_ACK, the out stream count in the client isshrunk to N - 2, the same to the in stream count in the server. The crashoccurs when the thread waiting for sndbuf is awake and sends the msg in anon-existing stream(N - 1), the call trace is as below: KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f] Call Trace: sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline] sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline] sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170 sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163 sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868 sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026 inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825 sock_sendmsg_nosec net/socket.c:722 [inline] sock_sendmsg+0xde/0x190 net/socket.c:745The fix is to add an unlikely check for the send stream number after thethread wakes up from the wait_for_sndbuf.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53432 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:firewire: net: fix use after free in fwnet_finish_incoming_packet()The netif_rx() function frees the skb so we can't dereference it tosave the skb->len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53517 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: do not update mtu if msg_max is too small in mtu negotiationWhen doing link mtu negotiation, a malicious peer may send Activate msgwith a very small mtu, e.g. 4 in Shuang's testing, without checking forthe minimum mtu, l->mtu will be set to 4 in tipc_link_proto_rcv(), thenn->links[bearer_id].mtu is set to 4294967228, which is a overflow of'4 - INT_H_SIZE - EMSG_OVERHEAD' in tipc_link_mss().With tipc_link.mtu = 4, tipc_link_xmit() kept printing the warning: tipc: Too large msg, purging xmit list 1 5 0 40 4! tipc: Too large msg, purging xmit list 1 15 0 60 4!And with tipc_link_entry.mtu 4294967228, a huge skb was allocated innamed_distribute(), and when purging it in tipc_link_xmit(), a crashwas even caused: general protection fault, probably for non-canonical address 0x2100001011000dd: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 6.3.0.neta #19 RIP: 0010:kfree_skb_list_reason+0x7e/0x1f0 Call Trace: skb_release_data+0xf9/0x1d0 kfree_skb_reason+0x40/0x100 tipc_link_xmit+0x57a/0x740 [tipc] tipc_node_xmit+0x16c/0x5c0 [tipc] tipc_named_node_up+0x27f/0x2c0 [tipc] tipc_node_write_unlock+0x149/0x170 [tipc] tipc_rcv+0x608/0x740 [tipc] tipc_udp_recv+0xdc/0x1f0 [tipc] udp_queue_rcv_one_skb+0x33e/0x620 udp_unicast_rcv_skb.isra.72+0x75/0x90 __udp4_lib_rcv+0x56d/0xc20 ip_protocol_deliver_rcu+0x100/0x2d0This patch fixes it by checking the new mtu against tipc_bearer_min_mtu(),and not updating mtu if it is too small.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53539 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix incomplete state save in rxe_requesterIf a send packet is dropped by the IP layer in rxe_requester()the call to rxe_xmit_packet() can fail with err == -EAGAIN.To recover, the state of the wqe is restored to the state beforethe packet was sent so it can be resent. However, the routinesthat save and restore the state miss a significnt part of thevariable state in the wqe, the dma struct which is used to processthrough the sge table. And, the state is not saved before the packetis built which modifies the dma struct.Under heavy stress testing with many QPs on a fast node sendinglarge messages to a slow node dropped packets are observed andthe resent packets are corrupted because the dma struct was notrestored. This patch fixes this behavior and allows the test casesto succeed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53705 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix out-of-bounds access in ipv6_find_tlv()optlen is fetched without checking whether there is more than one byte to parse.It can lead to out-of-bounds access.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53715 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hexApparently the hex passphrase mechanism does not work on newerchips/firmware (e.g. BCM4387). It seems there was a simple way ofpassing it in binary all along, so use that and avoid the hexification.OpenBSD has been doing it like this from the beginning, so this shouldwork on all chips.Also clear the structure before setting the PMK. This was leakinguninitialized stack contents to the device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53729 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: qmi_encdec: Restrict string length in decodeThe QMI TLV value for strings in a lot of qmi element info structuresaccount for null terminated strings with MAX_LEN + 1. If a string isactually MAX_LEN + 1 length, this will cause an out of bounds accesswhen the NULL character is appended in decoding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54193 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: cls_api: remove block_cb from driver_list before freeingError handler of tcf_block_bind() frees the whole bo->cb_list on error.However, by that time the flow_block_cb instances are already in the driverlist because driver ndo_setup_tc() callback is called before that up thecall chain in tcf_block_offload_cmd(). This leaves dangling pointers tofreed objects in the list and causes use-after-free[0]. Fix it by alsoremoving flow_block_cb instances from driver_list before deallocating them.[0]:[ 279.868433] ==================================================================[ 279.869964] BUG: KASAN: slab-use-after-free in flow_block_cb_setup_simple+0x631/0x7c0[ 279.871527] Read of size 8 at addr ffff888147e2bf20 by task tc/2963[ 279.873151] CPU: 6 PID: 2963 Comm: tc Not tainted 6.3.0-rc6+ #4[ 279.874273] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 279.876295] Call Trace:[ 279.876882] [ 279.877413] dump_stack_lvl+0x33/0x50[ 279.878198] print_report+0xc2/0x610[ 279.878987] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.879994] kasan_report+0xae/0xe0[ 279.880750] ? flow_block_cb_setup_simple+0x631/0x7c0[ 279.881744] ? mlx5e_tc_reoffload_flows_work+0x240/0x240 [mlx5_core][ 279.883047] flow_block_cb_setup_simple+0x631/0x7c0[ 279.884027] tcf_block_offload_cmd.isra.0+0x189/0x2d0[ 279.885037] ? tcf_block_setup+0x6b0/0x6b0[ 279.885901] ? mutex_lock+0x7d/0xd0[ 279.886669] ? __mutex_unlock_slowpath.constprop.0+0x2d0/0x2d0[ 279.887844] ? ingress_init+0x1c0/0x1c0 [sch_ingress][ 279.888846] tcf_block_get_ext+0x61c/0x1200[ 279.889711] ingress_init+0x112/0x1c0 [sch_ingress][ 279.890682] ? clsact_init+0x2b0/0x2b0 [sch_ingress][ 279.891701] qdisc_create+0x401/0xea0[ 279.892485] ? qdisc_tree_reduce_backlog+0x470/0x470[ 279.893473] tc_modify_qdisc+0x6f7/0x16d0[ 279.894344] ? tc_get_qdisc+0xac0/0xac0[ 279.895213] ? mutex_lock+0x7d/0xd0[ 279.896005] ? __mutex_lock_slowpath+0x10/0x10[ 279.896910] rtnetlink_rcv_msg+0x5fe/0x9d0[ 279.897770] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.898672] ? __sys_sendmsg+0xb5/0x140[ 279.899494] ? do_syscall_64+0x3d/0x90[ 279.900302] ? entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 279.901337] ? kasan_save_stack+0x2e/0x40[ 279.902177] ? kasan_save_stack+0x1e/0x40[ 279.903058] ? kasan_set_track+0x21/0x30[ 279.903913] ? kasan_save_free_info+0x2a/0x40[ 279.904836] ? ____kasan_slab_free+0x11a/0x1b0[ 279.905741] ? kmem_cache_free+0x179/0x400[ 279.906599] netlink_rcv_skb+0x12c/0x360[ 279.907450] ? rtnl_calcit.isra.0+0x2b0/0x2b0[ 279.908360] ? netlink_ack+0x1550/0x1550[ 279.909192] ? rhashtable_walk_peek+0x170/0x170[ 279.910135] ? kmem_cache_alloc_node+0x1af/0x390[ 279.911086] ? _copy_from_iter+0x3d6/0xc70[ 279.912031] netlink_unicast+0x553/0x790[ 279.912864] ? netlink_attachskb+0x6a0/0x6a0[ 279.913763] ? netlink_recvmsg+0x416/0xb50[ 279.914627] netlink_sendmsg+0x7a1/0xcb0[ 279.915473] ? netlink_unicast+0x790/0x790[ 279.916334] ? iovec_from_user.part.0+0x4d/0x220[ 279.917293] ? netlink_unicast+0x790/0x790[ 279.918159] sock_sendmsg+0xc5/0x190[ 279.918938] ____sys_sendmsg+0x535/0x6b0[ 279.919813] ? import_iovec+0x7/0x10[ 279.920601] ? kernel_sendmsg+0x30/0x30[ 279.921423] ? __copy_msghdr+0x3c0/0x3c0[ 279.922254] ? import_iovec+0x7/0x10[ 279.923041] ___sys_sendmsg+0xeb/0x170[ 279.923854] ? copy_msghdr_from_user+0x110/0x110[ 279.924797] ? ___sys_recvmsg+0xd9/0x130[ 279.925630] ? __perf_event_task_sched_in+0x183/0x470[ 279.926656] ? ___sys_sendmsg+0x170/0x170[ 279.927529] ? ctx_sched_in+0x530/0x530[ 279.928369] ? update_curr+0x283/0x4f0[ 279.929185] ? perf_event_update_userpage+0x570/0x570[ 279.930201] ? __fget_light+0x57/0x520[ 279.931023] ? __switch_to+0x53d/0xe70[ 27---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54253 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set page extent mapped after read_folio in relocate_one_pageOne of the CI runs triggered the following panic assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 ------------[ cut here ]------------ kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 sp : ffff800093213720 x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000 x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880 x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028 x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000 x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8 x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_set_dirty+0x38/0xa0 btrfs_page_set_dirty+0x58/0x88 relocate_one_page+0x204/0x5f0 relocate_file_extent_cluster+0x11c/0x180 relocate_data_extent+0xd0/0xf8 relocate_block_group+0x3d0/0x4e8 btrfs_relocate_block_group+0x2d8/0x490 btrfs_relocate_chunk+0x54/0x1a8 btrfs_balance+0x7f4/0x1150 btrfs_ioctl+0x10f0/0x20b8 __arm64_sys_ioctl+0x120/0x11d8 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x158 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)This is the same problem outlined in 17b17fcd6d44 ("btrfs:set_page_extent_mapped after read_folio in btrfs_cont_expand") , and thefix is the same. I originally looked for the same pattern elsewhere inour code, but mistakenly skipped over this code because I saw the pagecache readahead before we set_page_extent_mapped, not realizing thatthis was only in the !page case, that we can still end up with a!uptodate page and then do the btrfs_read_folio further down.The fix here is the same as the above mentioned patch, move theset_page_extent_mapped call to after the btrfs_read_folio() block tomake sure that we have the subpage blocksize stuff setup properly beforeusing the page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-6535 Severity: Moderate CVSS3 score: 6.5

Description: A flaw was found in the Linux kernel's NVMe driver. This issue may allow an unauthenticated malicious actor to send a set of crafted TCP packages when using NVMe over TCP, leading the NVMe driver to a NULL pointer dereference in the NVMe driver, causing kernel panic and a denial of service.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2398 Severity: Moderate CVSS3 score: 6.5

Description: When an application tells libcurl it wants to allow HTTP/2 server push, and the amount of received headers for the push surpasses the maximum allowed limit (1000), libcurl aborts the server push. When aborting, libcurl inadvertently does not free all the previously allocated headers and instead leaks the memory. Further, this error condition fails silently and is therefore not easily detected by an application.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2024-27415 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: confirm multicast packets before passing them up the stackconntrack nf_confirm logic cannot handle cloned skbs referencingthe same nf_conn entry, which will happen for multicast (broadcast)frames on bridges. Example: macvlan0 | br0 / \ ethX ethY ethX (or Y) receives a L2 multicast or broadcast packet containing an IP packet, flow is not yet in conntrack table. 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting. -> skb->_nfct now references a unconfirmed entry 2. skb is broad/mcast packet. bridge now passes clones out on each bridge interface. 3. skb gets passed up the stack. 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb and schedules a work queue to send them out on the lower devices. The clone skb->_nfct is not a copy, it is the same entry as the original skb. The macvlan rx handler then returns RX_HANDLER_PASS. 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.The Macvlan broadcast worker and normal confirm path will race.This race will not happen if step 2 already confirmed a clone. In thatcase later steps perform skb_clone() with skb->_nfct already confirmed (inhash table). This works fine.But such confirmation won't happen when eb/ip/nftables rules dropped thepackets before they reached the nf_confirm step in postrouting.Pablo points out that nf_conntrack_bridge doesn't allow use of statefulnat, so we can safely discard the nf_conn entry and let inet callconntrack again.This doesn't work for bridge netfilter: skb could have a nattransformation. Also bridge nf prevents re-invocation of inet preroutingvia 'sabotage_in' hook.Work around this problem by explicit confirmation of the entry at LOCAL_INtime, before upper layer has a chance to clone the unconfirmed entry.The downside is that this disables NAT and conntrack helpers.Alternative fix would be to add locking to all code parts that deal withunconfirmed packets, but even if that could be done in a sane way thisopens up other problems, for example:-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5For multicast case, only one of such conflicting mappings will becreated, conntrack only handles 1:1 NAT mappings.Users should set create a setup that explicitly marks such trafficNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypassthem, ruleset might have accept rules for untracked traffic already,so user-visible behaviour would change.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-3651 Severity: Moderate CVSS3 score: 6.5

Description: A vulnerability was identified in the kjd/idna library, specifically within the `idna.encode()` function, affecting version 3.6. The issue arises from the function's handling of crafted input strings, which can lead to quadratic complexity and consequently, a denial of service condition. This vulnerability is triggered by a crafted input that causes the `idna.encode()` function to process the input with considerable computational load, significantly increasing the processing time in a quadratic manner relative to the input size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-idna > 0-0 (version in image is 2.6-150000.3.6.1).

CVE-2024-41048 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:skmsg: Skip zero length skb in sk_msg_recvmsgWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarchplatform, the following kernel panic occurs: [...] Oops[#1]: CPU: 22 PID: 2824 Comm: test_progs Tainted: G OE 6.10.0-rc2+ #18 Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018 ... ... ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560 ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 0000000c (PPLV0 +PIE +PWE) EUEN: 00000007 (+FPE +SXE +ASXE -BTE) ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7) ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) BADV: 0000000000000040 PRID: 0014c011 (Loongson-64bit, Loongson-3C5000) Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...) Stack : ... Call Trace: [<9000000004162774>] copy_page_to_iter+0x74/0x1c0 [<90000000048bf6c0>] sk_msg_recvmsg+0x120/0x560 [<90000000049f2b90>] tcp_bpf_recvmsg_parser+0x170/0x4e0 [<90000000049aae34>] inet_recvmsg+0x54/0x100 [<900000000481ad5c>] sock_recvmsg+0x7c/0xe0 [<900000000481e1a8>] __sys_recvfrom+0x108/0x1c0 [<900000000481e27c>] sys_recvfrom+0x1c/0x40 [<9000000004c076ec>] do_syscall+0x8c/0xc0 [<9000000003731da4>] handle_syscall+0xc4/0x160 Code: ... ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception Kernel relocated by 0x3510000 .text @ 0x9000000003710000 .data @ 0x9000000004d70000 .bss @ 0x9000000006469400 ---[ end Kernel panic - not syncing: Fatal exception ]--- [...]This crash happens every time when running sockmap_skb_verdict_shutdownsubtest in sockmap_basic.This crash is because a NULL pointer is passed to page_address() in thesk_msg_recvmsg(). Due to the different implementations depending on thearchitecture, page_address(NULL) will trigger a panic on Loongarchplatform but not on x86 platform. So this bug was hidden on x86 platformfor a while, but now it is exposed on Loongarch platform. The root causeis that a zero length skb (skb->len == 0) was put on the queue.This zero length skb is a TCP FIN packet, which was sent by shutdown(),invoked in test_sockmap_skb_verdict_shutdown(): shutdown(p1, SHUT_WR);In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and nopage is put to this sge (see sg_set_page in sg_set_page), but this emptysge is queued into ingress_msg list.And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got bysg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes itto kmap_local_page() and to page_address(), then kernel panics.To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),if copy is zero, that means it's a zero length skb, skip invokingcopy_page_to_iter(). We are using the EFAULT return triggered bycopy_page_to_iter to check for is_fin in tcp_bpf.c.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46737 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix kernel crash if commands allocation failsIf the commands allocation fails in nvmet_tcp_alloc_cmds()the kernel crashes in nvmet_tcp_release_queue_work() because ofa NULL pointer dereference. nvmet: failed to install queue 0 cntlid 1 ret 6 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008Fix the bug by setting queue->nr_cmds to zero in casenvmet_tcp_alloc_cmd() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46854 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dpaa: Pad packets to ETH_ZLENWhen sending packets under 60 bytes, up to three bytes of the bufferfollowing the data may be leaked. Avoid this by extending all packets toETH_ZLEN, ensuring nothing is leaked in the padding. This bug can bereproduced by running $ ping -s 11 destination

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47685 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sendinggarbage on the four reserved tcp bits (th->res1)Use skb_put_zero() to clear the whole TCP header,as done in nf_reject_ip_tcphdr_put()BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-8096 Severity: Moderate CVSS3 score: 6.5

Description: When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine. If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2024-9287 Severity: Moderate CVSS3 score: 6.5

Description: A vulnerability has been found in the CPython `venv` module and CLI where path names provided when creating a virtual environment were not quoted properly, allowing the creator to inject commands into virtual environment "activation" scripts (ie "source venv/bin/activate"). This means that attacker-controlled virtual environments are able to run commands when the virtual environment is activated. Virtual environments which are not created by an attacker or which aren't activated before being used (ie "./venv/bin/python") are not affected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

CVE-2025-11563 Severity: Moderate CVSS3 score: 6.5

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-13836 Severity: Moderate CVSS3 score: 6.5

Description: When reading an HTTP response from a server, if no read amount is specified, the default behavior will be to use Content-Length. This allows a malicious server to cause the client to read large amounts of data into memory, potentially causing OOM or other DoS.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-14512 Severity: Moderate CVSS3 score: 6.5

Description: A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools < 2.70.5-150400.3.29.1 (version in image is 2.70.5-150400.3.23.1).

CVE-2025-15282 Severity: Moderate CVSS3 score: 6.5

Description: User-controlled data URLs parsed by urllib.request.DataHandler allow injecting headers through newlines in the data URL mediatype.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-24528 Severity: Moderate CVSS3 score: 6.5

Description: In MIT Kerberos 5 (aka krb5) before 1.22 (with incremental propagation), there is an integer overflow for a large update size to resize() in kdb_log.c. An authenticated attacker can cause an out-of-bounds write and kadmind daemon crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2025-38146 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix the dead loop of MPLS parseThe unexpected MPLS packet may not end with the bottom label stack.When there are many stacks, The label count value has wrapped around.A dead loop occurs, soft lockup/CPU stuck finally.stack backtrace:UBSAN: array-index-out-of-bounds in /build/linux-0Pa0xK/linux-5.15.0/net/openvswitch/flow.c:662:26index -1 is out of range for type '__be32 [3]'CPU: 34 PID: 0 Comm: swapper/34 Kdump: loaded Tainted: G OE 5.15.0-121-generic #131-UbuntuHardware name: Dell Inc. PowerEdge C6420/0JP9TF, BIOS 2.12.2 07/14/2021Call Trace: show_stack+0x52/0x5c dump_stack_lvl+0x4a/0x63 dump_stack+0x10/0x16 ubsan_epilogue+0x9/0x36 __ubsan_handle_out_of_bounds.cold+0x44/0x49 key_extract_l3l4+0x82a/0x840 [openvswitch] ? kfree_skbmem+0x52/0xa0 key_extract+0x9c/0x2b0 [openvswitch] ovs_flow_key_extract+0x124/0x350 [openvswitch] ovs_vport_receive+0x61/0xd0 [openvswitch] ? kernel_init_free_pages.part.0+0x4a/0x70 ? get_page_from_freelist+0x353/0x540 netdev_port_receive+0xc4/0x180 [openvswitch] ? netdev_port_receive+0x180/0x180 [openvswitch] netdev_frame_hook+0x1f/0x40 [openvswitch] __netif_receive_skb_core.constprop.0+0x23a/0xf00 __netif_receive_skb_list_core+0xfa/0x240 netif_receive_skb_list_internal+0x18e/0x2a0 napi_complete_done+0x7a/0x1c0 bnxt_poll+0x155/0x1c0 [bnxt_en] __napi_poll+0x30/0x180 net_rx_action+0x126/0x280 ? bnxt_msix+0x67/0x80 [bnxt_en] handle_softirqs+0xda/0x2d0 irq_exit_rcu+0x96/0xc0 common_interrupt+0x8e/0xa0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38224 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_pciefd: refine error prone echo_skb_max handling logicecho_skb_max should define the supported upper limit of echo_skb[]allocated inside the netdevice's priv. The corresponding size valueprovided by this driver to alloc_candev() is KVASER_PCIEFD_CAN_TX_MAX_COUNTwhich is 17.But later echo_skb_max is rounded up to the nearest power of two (for themax case, that would be 32) and the tx/ack indices calculated furtherduring tx/rx may exceed the upper array boundary. Kasan reported this forthe ack case inside kvaser_pciefd_handle_ack_packet(), though the xmitfunction has actually caught the same thing earlier. BUG: KASAN: slab-out-of-bounds in kvaser_pciefd_handle_ack_packet+0x2d7/0x92a drivers/net/can/kvaser_pciefd.c:1528 Read of size 8 at addr ffff888105e4f078 by task swapper/4/0 CPU: 4 UID: 0 PID: 0 Comm: swapper/4 Not tainted 6.15.0 #12 PREEMPT(voluntary) Call Trace: dump_stack_lvl lib/dump_stack.c:122 print_report mm/kasan/report.c:521 kasan_report mm/kasan/report.c:634 kvaser_pciefd_handle_ack_packet drivers/net/can/kvaser_pciefd.c:1528 kvaser_pciefd_read_packet drivers/net/can/kvaser_pciefd.c:1605 kvaser_pciefd_read_buffer drivers/net/can/kvaser_pciefd.c:1656 kvaser_pciefd_receive_irq drivers/net/can/kvaser_pciefd.c:1684 kvaser_pciefd_irq_handler drivers/net/can/kvaser_pciefd.c:1733 __handle_irq_event_percpu kernel/irq/handle.c:158 handle_irq_event kernel/irq/handle.c:210 handle_edge_irq kernel/irq/chip.c:833 __common_interrupt arch/x86/kernel/irq.c:296 common_interrupt arch/x86/kernel/irq.c:286 Tx max count definitely matters for kvaser_pciefd_tx_avail(), but for seqnumbers' generation that's not the case - we're free to calculate them aswould be more convenient, not taking tx max count into account. The onlydownside is that the size of echo_skb[] should correspond to the max seqnumber (not tx max count), so in some situations a bit more memory wouldbe consumed than could be.Thus make the size of the underlying echo_skb[] sufficient for the roundedmax tx value.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38512 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: prevent A-MSDU attacks in mesh networksThis patch is a mitigation to prevent the A-MSDU spoofing vulnerabilityfor mesh networks. The initial update to the IEEE 802.11 standard, inresponse to the FragAttacks, missed this case (CVE-2025-27558). It canbe considered a variant of CVE-2020-24588 but for mesh networks.This patch tries to detect if a standard MSDU was turned into an A-MSDUby an adversary. This is done by parsing a received A-MSDU as a standardMSDU, calculating the length of the Mesh Control header, and seeing ifthe 6 bytes after this header equal the start of an rfc1042 header. Ifequal, this is a strong indication of an ongoing attack attempt.This defense was tested with mac80211_hwsim against a mesh network thatuses an empty Mesh Address Extension field, i.e., when four addressesare used, and when using a 12-byte Mesh Address Extension field, i.e.,when six addresses are used. Functionality of normal MSDUs and A-MSDUswas also tested, and confirmed working, when using both an empty and12-byte Mesh Address Extension field.It was also tested with mac80211_hwsim that A-MSDU attacks in non-meshnetworks keep being detected and prevented.Note that the vulnerability being patched, and the defense beingimplemented, was also discussed in the following paper and in thefollowing IEEE 802.11 presentation:https://papers.mathyvanhoef.com/wisec2025.pdfhttps://mentor.ieee.org/802.11/dcn/25/11-25-0949-00-000m-a-msdu-mesh-spoof-protection.docx

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39825 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix race with concurrent opens in rename(2)Besides sending the rename request to the server, the rename processalso involves closing any deferred close, waiting for outstanding I/Oto complete as well as marking all existing open handles as deleted toprevent them from deferring closes, which increases the race windowfor potential concurrent opens on the target file.Fix this by unhashing the dentry in advance to prevent any concurrentopens on the target.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40300 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/vmscape: Add conditional IBPB mitigationVMSCAPE is a vulnerability that exploits insufficient branch predictorisolation between a guest and a userspace hypervisor (like QEMU). Existingmitigations already protect kernel/KVM from a malicious guest. Userspacecan additionally be protected by flushing the branch predictors after aVMexit.Since it is the userspace that consumes the poisoned branch predictors,conditionally issue an IBPB after a VMexit and before returning touserspace. Workloads that frequently switch between hypervisor anduserspace will incur the most overhead from the new IBPB.This new IBPB is not integrated with the existing IBPB sites. Forinstance, a task can use the existing speculation control prctl() toget an IBPB at context switch time. With this implementation, theIBPB is doubled up: one at context switch and another before runninguserspace.The intent is to integrate and optimize these cases post-embargo.[ dhansen: elaborate on suboptimal IBPB solution ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-47268 Severity: Moderate CVSS3 score: 6.5

Description: ping in iputils before 20250602 allows a denial of service (application error or incorrect data collection) via a crafted ICMP Echo Reply packet, because of a signed 64-bit integer overflow in timestamp multiplication.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
iputils > 0-0 (version in image is 20211215-150400.3.22.1).

CVE-2025-58149 Severity: Moderate CVSS3 score: 6.5

Description: When passing through PCI devices, the detach logic in libxl won't removeaccess permissions to any 64bit memory BARs the device might have. As aresult a domain can still have access any 64bit memory BAR when suchdevice is no longer assigned to the domain.For PV domains the permission leak allows the domain itself to map the memoryin the page-tables. For HVM it would require a compromised device model orstubdomain to map the leaked memory into the HVM domain p2m.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2025-68468 Severity: Moderate CVSS3 score: 6.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending unsolicited announcements containing CNAME resource records pointing it to resource records with short TTLs. As soon as they expire avahi-daemon crashes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2025-68471 Severity: Moderate CVSS3 score: 6.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, avahi-daemon can be crashed by sending 2 unsolicited announcements with CNAME resource records 2 seconds apart.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2025-71096 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Check for the presence of LS_NLA_TYPE_DGID correctlyThe netlink response for RDMA_NL_LS_OP_IP_RESOLVE should always have aLS_NLA_TYPE_DGID attribute, it is invalid if it does not.Use the nl parsing logic properly and call nla_parse_deprecated() to fillthe nlattrs array and then directly index that array to get the data forthe DGID. Just fail if it is NULL.Remove the for loop searching for the nla, and squash the validation andparsing into one function.Fixes an uninitialized read from the stack triggered by userspace if itdoes not provide the DGID to a kernel initiated RDMA_NL_LS_OP_IP_RESOLVEquery. BUG: KMSAN: uninit-value in hex_byte_pack include/linux/hex.h:13 [inline] BUG: KMSAN: uninit-value in ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 hex_byte_pack include/linux/hex.h:13 [inline] ip6_string+0xef4/0x13a0 lib/vsprintf.c:1490 ip6_addr_string+0x18a/0x3e0 lib/vsprintf.c:1509 ip_addr_string+0x245/0xee0 lib/vsprintf.c:1633 pointer+0xc09/0x1bd0 lib/vsprintf.c:2542 vsnprintf+0xf8a/0x1bd0 lib/vsprintf.c:2930 vprintk_store+0x3ae/0x1530 kernel/printk/printk.c:2279 vprintk_emit+0x307/0xcd0 kernel/printk/printk.c:2426 vprintk_default+0x3f/0x50 kernel/printk/printk.c:2465 vprintk+0x36/0x50 kernel/printk/printk_safe.c:82 _printk+0x17e/0x1b0 kernel/printk/printk.c:2475 ib_nl_process_good_ip_rsep drivers/infiniband/core/addr.c:128 [inline] ib_nl_handle_ip_res_resp+0x963/0x9d0 drivers/infiniband/core/addr.c:141 rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline] rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0xefa/0x11c0 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0xf04/0x12b0 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x10b3/0x1250 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x333/0x3d0 net/socket.c:729 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2617 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2671 __sys_sendmsg+0x1aa/0x300 net/socket.c:2703 __compat_sys_sendmsg net/compat.c:346 [inline] __do_compat_sys_sendmsg net/compat.c:353 [inline] __se_compat_sys_sendmsg net/compat.c:350 [inline] __ia32_compat_sys_sendmsg+0xa4/0x100 net/compat.c:350 ia32_sys_call+0x3f6c/0x4310 arch/x86/include/generated/asm/syscalls_32.h:371 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x150 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:3

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71104 Severity: Moderate CVSS3 score: 6.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timerWhen advancing the target expiration for the guest's APIC timer in periodicmode, set the expiration to "now" if the target expiration is in the past(similar to what is done in update_target_expiration()). Blindly addingthe period to the previous target expiration can result in KVM generatinga practically unbounded number of hrtimer IRQs due to programming anexpired timer over and over. In extreme scenarios, e.g. if userspacepauses/suspends a VM for an extended duration, this can even cause hardlockups in the host.Currently, the bug only affects Intel CPUs when using the hypervisor timer(HV timer), a.k.a. the VMX preemption timer. Unlike the software timer,a.k.a. hrtimer, which KVM keeps running even on exits to userspace, theHV timer only runs while the guest is active. As a result, if the vCPUdoes not run for an extended duration, there will be a huge gap betweenthe target expiration and the current time the vCPU resumes running.Because the target expiration is incremented by only one period on eachtimer expiration, this leads to a series of timer expirations occurringrapidly after the vCPU/VM resumes.More critically, when the vCPU first triggers a periodic HV timerexpiration after resuming, advancing the expiration by only one periodwill result in a target expiration in the past. As a result, the deltamay be calculated as a negative value. When the delta is converted intoan absolute value (tscdeadline is an unsigned u64), the resulting valuecan overflow what the HV timer is capable of programming. I.e. the largevalue will exceed the VMX Preemption Timer's maximum bit width ofcpu_preemption_timer_multi + 32, and thus cause KVM to switch from theHV timer to the software timer (hrtimers).After switching to the software timer, periodic timer expiration callbacksmay be executed consecutively within a single clock interrupt handler,because hrtimers honors KVM's request for an expiration in the past andimmediately re-invokes KVM's callback after reprogramming. And becausethe interrupt handler runs with IRQs disabled, restarting KVM's hrtimerover and over until the target expiration is advanced to "now" can resultin a hard lockup.E.g. the following hard lockup was triggered in the host when running aWindows VM (only relevant because it used the APIC timer in periodic mode)after resuming the VM from a long suspend (in the host). NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advance_periodic_target_expiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: apic_timer_fn+0x31/0x50 [kvm] __hrtimer_run_queues+0x100/0x280 hrtimer_interrupt+0x100/0x210 ? ttwu_do_wakeup+0x19/0x160 smp_apic_timer_interrupt+0x6a/0x130 apic_timer_interrupt+0xf/0x20 Moreover, if the suspend duration of the virtual machine is not long enoughto trigger a hard lockup in this scenario, since commit 98c25ead5eda("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVMwill continue using the software timer until the guest reprograms the APICtimer in some way. Since the periodic timer does not require frequent APICtimer register programming, the guest may continue to use the softwaretimer in ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8194 Severity: Moderate CVSS3 score: 6.5

Description: There is a defect in the CPython "tarfile" module affecting the "TarFile" extraction and entry enumeration APIs. The tar implementation would process tar archives with negative offsets without error, resulting in an infinite loop and deadlock during the parsing of maliciously crafted tar archives. This vulnerability can be mitigated by including the following patch after importing the "tarfile" module: https://gist.github.com/sethmlarson/1716ac5b82b73dbcbf23ad2eff8b33e1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2026-0865 Severity: Moderate CVSS3 score: 6.5

Description: User-controlled header names and values containing newlines can allow injecting HTTP headers.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2021-47634 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix race condition between ctrl_cdev_ioctl and ubi_cdev_ioctlHulk Robot reported a KASAN report about use-after-free: ================================================================== BUG: KASAN: use-after-free in __list_del_entry_valid+0x13d/0x160 Read of size 8 at addr ffff888035e37d98 by task ubiattach/1385 [...] Call Trace: klist_dec_and_del+0xa7/0x4a0 klist_put+0xc7/0x1a0 device_del+0x4d4/0xed0 cdev_device_del+0x1a/0x80 ubi_attach_mtd_dev+0x2951/0x34b0 [ubi] ctrl_cdev_ioctl+0x286/0x2f0 [ubi] Allocated by task 1414: device_add+0x60a/0x18b0 cdev_device_add+0x103/0x170 ubi_create_volume+0x1118/0x1a10 [ubi] ubi_cdev_ioctl+0xb7f/0x1ba0 [ubi] Freed by task 1385: cdev_device_del+0x1a/0x80 ubi_remove_volume+0x438/0x6c0 [ubi] ubi_cdev_ioctl+0xbf4/0x1ba0 [ubi] [...] ==================================================================The lock held by ctrl_cdev_ioctl is ubi_devices_mutex, but the lock heldby ubi_cdev_ioctl is ubi->device_mutex. Therefore, the two locks can beconcurrent.ctrl_cdev_ioctl contains two operations: ubi_attach and ubi_detach.ubi_detach is bug-free because it uses reference counting to preventconcurrency. However, uif_init and uif_close in ubi_attach may race withubi_cdev_ioctl.uif_init will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_add_volume // sysfs exist kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume cdev_del // double free cdev_device_delAnd uif_close will race with ubi_cdev_ioctl as in the following stack. cpu1 cpu2 cpu3_______________________|________________________|______________________ctrl_cdev_ioctl ubi_attach_mtd_dev uif_init ubi_cdev_ioctl ubi_create_volume cdev_device_add ubi_debugfs_init_dev //error goto out_uif; uif_close kill_volumes ubi_cdev_ioctl ubi_remove_volume cdev_device_del // first free ubi_free_volume // double freeThe cause of this problem is that commit 714fb87e8bc0 make device"available" before it becomes accessible via sysfs. Therefore, weroll back the modification. We will fix the race condition betweenubi device creation and udev by removing ubi_get_device invol_attribute_show and dev_attribute_show.This avoids accessinguninitialized ubi_devices[ubi_num].ubi_get_device is used to prevent devices from being deleted duringsysfs execution. However, now kernfs ensures that devices will notbe deleted before all reference counting are released.The key process is shown in the following stack.device_del device_remove_attrs device_remove_groups sysfs_remove_groups sysfs_remove_group remove_files kernfs_remove_by_name kernfs_remove_by_name_ns __kernfs_remove kernfs_drain

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50496 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: Fix UAF in destroy()Dm_cache also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50616 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Use different devices for resource allocation and DT lookupFollowing by the below discussion, there's the potential UAF issuebetween regulator and mfd.https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/From the analysis of YingliangCPU A |CPU Bmt6370_probe() | devm_mfd_add_devices() | |mt6370_regulator_probe() | regulator_register() | //allocate init_data and add it to devres | regulator_of_get_init_data()i2c_unregister_device() | device_del() | devres_release_all() | // init_data is freed | release_nodes() | | // using init_data causes UAF | regulator_register()It's common to use mfd core to create child device for the regulator.In order to do the DT lookup for init data, the child that registeredthe regulator would pass its parent as the parameter. And this causesinit data resource allocated to its parent, not itself. The issue happenwhen parent device is going to release and regulator core is still doingsome operation of init data constraint for the regulator of child device.To fix it, this patch expand 'regulator_register' API to use thedifferent devices for init data allocation and DT lookup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53285 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add bounds checking in get_max_inline_xattr_value_size()Normally the extended attributes in the inode body would have beenchecked when the inode is first opened, but if someone is writing tothe block device while the file system is mounted, it's possible forthe inode table to get corrupted. Add bounds checking to avoidreading beyond the end of allocated memory if this happens.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53587 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Sync IRQ works before buffer destructionIf something was written to the buffer just before destruction,it may be possible (maybe not in a real system, but it didhappen in ARCH=um with time-travel) to destroy the ringbufferbefore the IRQ work ran, leading this KASAN report (or a crashwithout KASAN): BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a Read of size 8 at addr 000000006d640a48 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7 Stack: 60c4f20f 0c203d48 41b58ab3 60f224fc 600477fa 60f35687 60c4f20f 601273dd 00000008 6101eb00 6101eab0 615be548 Call Trace: [<60047a58>] show_stack+0x25e/0x282 [<60c609e0>] dump_stack_lvl+0x96/0xfd [<60c50d4c>] print_report+0x1a7/0x5a8 [<603078d3>] kasan_report+0xc1/0xe9 [<60308950>] __asan_report_load8_noabort+0x1b/0x1d [<60232844>] irq_work_run_list+0x11a/0x13a [<602328b4>] irq_work_tick+0x24/0x34 [<6017f9dc>] update_process_times+0x162/0x196 [<6019f335>] tick_sched_handle+0x1a4/0x1c3 [<6019fd9e>] tick_sched_timer+0x79/0x10c [<601812b9>] __hrtimer_run_queues.constprop.0+0x425/0x695 [<60182913>] hrtimer_interrupt+0x16c/0x2c4 [<600486a3>] um_timer+0x164/0x183 [...] Allocated by task 411: save_stack_trace+0x99/0xb5 stack_trace_save+0x81/0x9b kasan_save_stack+0x2d/0x54 kasan_set_track+0x34/0x3e kasan_save_alloc_info+0x25/0x28 ____kasan_kmalloc+0x8b/0x97 __kasan_kmalloc+0x10/0x12 __kmalloc+0xb2/0xe8 load_elf_phdrs+0xee/0x182 [...] The buggy address belongs to the object at 000000006d640800 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 584 bytes inside of freed 1024-byte region [000000006d640800, 000000006d640c00)Add the appropriate irq_work_sync() so the work finishes beforethe buffers are destroyed.Prior to the commit in the Fixes tag below, there was only asingle global IRQ work, so this issue didn't exist.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53651 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:Input: exc3000 - properly stop timer on shutdownWe need to stop the timer on driver unbind or probe failures, otherwisewe get UAF/Oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54310 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: message: mptlan: Fix use after free bug in mptlan_remove() due to race conditionmptlan_probe() calls mpt_register_lan_device() which initializes the&priv->post_buckets_task workqueue. A call tompt_lan_wake_post_buckets_task() will subsequently start the work.During driver unload in mptlan_remove() the following race may occur:CPU0 CPU1 |mpt_lan_post_receive_buckets_work()mptlan_remove() | free_netdev() | kfree(dev); | | | dev->mtu | //useFix this by finishing the work prior to cleaning up in mptlan_remove().[mkp: we really should remove mptlan instead of attempting to fix it]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7256 Severity: Moderate CVSS3 score: 6.4

Description: In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns. This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block. A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).

CVE-2024-26875 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix uaf in pvr2_context_set_notify[Syzbot reported]BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Workqueue: usb_hub_wq hub_eventCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline] pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272Freed by task 906:kasan_save_stack+0x33/0x50 mm/kasan/common.c:47kasan_save_track+0x14/0x30 mm/kasan/common.c:68kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640poison_slab_object mm/kasan/common.c:241 [inline]__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257kasan_slab_free include/linux/kasan.h:184 [inline]slab_free_hook mm/slub.c:2121 [inline]slab_free mm/slub.c:4299 [inline]kfree+0x105/0x340 mm/slub.c:4409pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158[Analyze]Task A set disconnect_flag = !0, which resulted in Task B's condition being metand releasing mp, leading to this issue.[Fix]Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()to avoid this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26996 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport errorWhen ncm function is working and then stop usb0 interface for link down,eth_stop() is called. At this piont, accidentally if usb transport errorshould happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.After that, ncm_disable() is called to disable for ncm unbindbut gether_disconnect() is never called since 'in_ep' is not enabled.As the result, ncm object is released in ncm unbindbut 'dev->port_usb' associated to 'ncm->port' is not NULL.And when ncm bind again to recover netdev, ncm object is reallocatedbut usb0 interface is already associated to previous released ncm object.Therefore, once usb0 interface is up and eth_start_xmit() is called,released ncm object is dereferrenced and it might cause use-after-free memory.[function unlink via configfs] usb0: eth_stop dev->port_usb=ffffff9b179c3200 --> error happens in usb_ep_enable(). NCM: ncm_disable: ncm=ffffff9b179c3200 --> no gether_disconnect() since ncm->port.in_ep->enabled is false. NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200 NCM: ncm_free: ncm free ncm=ffffff9b179c3200 <-- released ncm[function link via configfs] NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000 NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000 NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0 usb0: eth_open dev->port_usb=ffffff9b179c3200 <-- previous released ncm usb0: eth_start dev->port_usb=ffffff9b179c3200 <-- eth_start_xmit() --> dev->wrap() Unable to handle kernel paging request at virtual address dead00000000014fThis patch addresses the issue by checking if 'ncm->netdev' is not NULL atncm_disable() to call gether_disconnect() to deassociate 'dev->port_usb'.It's more reasonable to check 'ncm->netdev' to call gether_connect/disconnectrather than check 'ncm->port.in_ep->enabled' since it might not be enabledbut the gether connection might be established.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36012 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: msft: fix slab-use-after-free in msft_do_close()Tying the msft->data lifetime to hdev by freeing it inhci_release_dev() to fix the following case:[use]msft_do_close() msft = hdev->msft_data; if (!msft) ...(1) <- passed. return; mutex_lock(&msft->filter_lock); ...(4) <- used after freed.[free]msft_unregister() msft = hdev->msft_data; hdev->msft_data = NULL; ...(2) kfree(msft); ...(3) <- msft is freed.==================================================================BUG: KASAN: slab-use-after-free in __mutex_lock_commonkernel/locking/mutex.c:587 [inline]BUG: KASAN: slab-use-after-free in __mutex_lock+0x8f/0xc30kernel/locking/mutex.c:752Read of size 8 at addr ffff888106cbbca8 by task kworker/u5:2/309

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38577 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflowThere is a possibility of buffer overflow inshow_rcu_tasks_trace_gp_kthread() if counters, passedto sprintf() are huge. Counter numbers, needed for thisare unrealistically high, but buffer overflow is stillpossible.Use snprintf() with buffer size instead of sprintf().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41040 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix UAF when resolving a clashKASAN reports the following UAF: BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] Read of size 1 at addr ffff888c07603600 by task handler130/6469 Call Trace: dump_stack_lvl+0x48/0x70 print_address_description.constprop.0+0x33/0x3d0 print_report+0xc0/0x2b0 kasan_report+0xd0/0x120 __asan_load1+0x6c/0x80 tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct] tcf_ct_act+0x886/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 __irq_exit_rcu+0x82/0xc0 irq_exit_rcu+0xe/0x20 common_interrupt+0xa1/0xb0 asm_common_interrupt+0x27/0x40 Allocated by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_alloc_info+0x1e/0x40 __kasan_krealloc+0x133/0x190 krealloc+0xaa/0x130 nf_ct_ext_add+0xed/0x230 [nf_conntrack] tcf_ct_act+0x1095/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491 Freed by task 6469: kasan_save_stack+0x38/0x70 kasan_set_track+0x25/0x40 kasan_save_free_info+0x2b/0x60 ____kasan_slab_free+0x180/0x1f0 __kasan_slab_free+0x12/0x30 slab_free_freelist_hook+0xd2/0x1a0 __kmem_cache_free+0x1a2/0x2f0 kfree+0x78/0x120 nf_conntrack_free+0x74/0x130 [nf_conntrack] nf_ct_destroy+0xb2/0x140 [nf_conntrack] __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack] nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack] __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack] tcf_ct_act+0x12ad/0x1350 [act_ct] tcf_action_exec+0xf8/0x1f0 fl_classify+0x355/0x360 [cls_flower] __tcf_classify+0x1fd/0x330 tcf_classify+0x21c/0x3c0 sch_handle_ingress.constprop.0+0x2c5/0x500 __netif_receive_skb_core.constprop.0+0xb25/0x1510 __netif_receive_skb_list_core+0x220/0x4c0 netif_receive_skb_list_internal+0x446/0x620 napi_complete_done+0x157/0x3d0 gro_cell_poll+0xcf/0x100 __napi_poll+0x65/0x310 net_rx_action+0x30c/0x5c0 __do_softirq+0x14f/0x491The ct may be dropped if a clash has been resolved but is still passed tothe tcf_ct_flow_table_process_conn function for further usage. This issuecan be fixed by retrieving ct from skb again after confirming conntrack.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41070 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().It looks up `stt` from tablefd, but then continues to use it after doingfdput() on the returned fd. After the fdput() the tablefd is free to beclosed by another thread. The close calls kvm_spapr_tce_release() andthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.Although there are calls to rcu_read_lock() inkvm_spapr_tce_attach_iommu_group() they are not sufficient to preventthe UAF, because `stt` is used outside the locked regions.With an artifcial delay after the fdput() and a userspace program whichtriggers the race, KASAN detects the UAF: BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505 CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1 Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV Call Trace: dump_stack_lvl+0xb4/0x108 (unreliable) print_report+0x2b4/0x6ec kasan_report+0x118/0x2b0 __asan_load4+0xb8/0xd0 kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm] kvm_vfio_set_attr+0x524/0xac0 [kvm] kvm_device_ioctl+0x144/0x240 [kvm] sys_ioctl+0x62c/0x1810 system_call_exception+0x190/0x440 system_call_vectored_common+0x15c/0x2ec ... Freed by task 0: ... kfree+0xec/0x3e0 release_spapr_tce_table+0xd4/0x11c [kvm] rcu_core+0x568/0x16a0 handle_softirqs+0x23c/0x920 do_softirq_own_stack+0x6c/0x90 do_softirq_own_stack+0x58/0x90 __irq_exit_rcu+0x218/0x2d0 irq_exit+0x30/0x80 arch_local_irq_restore+0x128/0x230 arch_local_irq_enable+0x1c/0x30 cpuidle_enter_state+0x134/0x5cc cpuidle_enter+0x6c/0xb0 call_cpuidle+0x7c/0x100 do_idle+0x394/0x410 cpu_startup_entry+0x60/0x70 start_secondary+0x3fc/0x410 start_secondary_prolog+0x10/0x14Fix it by delaying the fdput() until `stt` is no longer in use, whichis effectively the entire function. To keep the patch minimal add a callto fdput() at each of the existing return paths. Future work can convertthe function to goto or __cleanup style cleanup.With the fix in place the test case no longer triggers the UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41073 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: avoid double free special payloadIf a discard request needs to be retried, and that retry may fail beforea new special payload is added, a double free will result. Clear theRQF_SPECIAL_LOAD when the request is cleaned.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43900 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: xc2028: avoid use-after-free in load_firmware_cb()syzkaller reported use-after-free in load_firmware_cb() [1].The reason is because the module allocated a struct tuner in tuner_probe(),and then the module initialization failed, the struct tuner was released.A worker which created during module initialization accesses this structtuner later, it caused use-after-free.The process is as follows:task-6504 worker_threadtuner_probe <= alloc dvb_frontend [2]...request_firmware_nowait <= create a worker...tuner_remove <= free dvb_frontend... request_firmware_work_func <= the firmware is ready load_firmware_cb <= but now the dvb_frontend has been freedTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it isnull, report a warning and just return.[1]: ================================================================== BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0 Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504 Call trace: load_firmware_cb+0x1310/0x17a0 request_firmware_work_func+0x128/0x220 process_one_work+0x770/0x1824 worker_thread+0x488/0xea0 kthread+0x300/0x430 ret_from_fork+0x10/0x20 Allocated by task 6504: kzalloc tuner_probe+0xb0/0x1430 i2c_device_probe+0x92c/0xaf0 really_probe+0x678/0xcd0 driver_probe_device+0x280/0x370 __device_attach_driver+0x220/0x330 bus_for_each_drv+0x134/0x1c0 __device_attach+0x1f4/0x410 device_initial_probe+0x20/0x30 bus_probe_device+0x184/0x200 device_add+0x924/0x12c0 device_register+0x24/0x30 i2c_new_device+0x4e0/0xc44 v4l2_i2c_new_subdev_board+0xbc/0x290 v4l2_i2c_new_subdev+0xc8/0x104 em28xx_v4l2_init+0x1dd0/0x3770 Freed by task 6504: kfree+0x238/0x4e4 tuner_remove+0x144/0x1c0 i2c_device_remove+0xc8/0x290 __device_release_driver+0x314/0x5fc device_release_driver+0x30/0x44 bus_remove_device+0x244/0x490 device_del+0x350/0x900 device_unregister+0x28/0xd0 i2c_unregister_device+0x174/0x1d0 v4l2_device_unregister+0x224/0x380 em28xx_v4l2_init+0x1d90/0x3770 The buggy address belongs to the object at ffff8000d7ca2000 which belongs to the cache kmalloc-2k of size 2048 The buggy address is located 776 bytes inside of 2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800) The buggy address belongs to the page: page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0 flags: 0x7ff800000000100(slab) raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000 raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================[2] Actually, it is allocated for struct tuner, and dvb_frontend is inside.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46673 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aacraid: Fix double-free on probe failureaac_probe_one() calls hardware-specific init functions through theaac_driver_ident::init pointer, all of which eventually call down toaac_init_adapter().If aac_init_adapter() fails after allocating memory for aac_dev::queues,it frees the memory but does not clear that member.After the hardware-specific init function returns an error,aac_probe_one() goes down an error path that frees the memory pointed toby aac_dev::queues, resulting.in a double-free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50183 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instanceDeleting an NPIV instance requires all fabric ndlps to be released beforean NPIV's resources can be torn down. Failure to release fabric ndlpsbeforehand opens kref imbalance race conditions. Fix by forcing the DA_IDto complete synchronously with usage of wait_queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57917 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:topology: Keep the cpumask unchanged when printing cpumapDuring fuzz testing, the following warning was discovered: different return values (15 and 11) from vsnprintf("%*pbl ", ...) test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmap_print_to_buf+0x89/0x100 core_siblings_list_read+0x7e/0xb0 kernfs_file_read_iter+0x15b/0x270 new_sync_read+0x153/0x260 vfs_read+0x215/0x290 ksys_read+0xb9/0x160 do_syscall_64+0x56/0x100 entry_SYSCALL_64_after_hwframe+0x78/0xe2The call trace shows that kvasprintf() reported this warning during theprinting of core_siblings_list. kvasprintf() has several steps: (1) First, calculate the length of the resulting formatted string. (2) Allocate a buffer based on the returned length. (3) Then, perform the actual string formatting. (4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.If the core_cpumask is modified between steps (1) and (3), the lengthsobtained in these two steps may not match. Indeed our test includes cpuhotplugging, which should modify core_cpumask while printing.To fix this issue, cache the cpumask into a temporary variable beforecalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchangedduring the printing process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21855 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Don't reference skb after sending to VIOSPreviously, after successfully flushing the xmit buffer to VIOS,the tx_bytes stat was incremented by the length of the skb.It is invalid to access the skb memory after sending the buffer tothe VIOS because, at any point after sending, the VIOS can triggeran interrupt to free this memory. A race between reading skb->lenand freeing the skb is possible (especially during LPM) and willresult in use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic] Read of size 4 at addr c00000024eb48a70 by task hxecom/14495 <...> Call Trace: [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable) [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0 [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8 [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0 [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic] [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358 <...> Freed by task 0: kasan_save_stack+0x34/0x68 kasan_save_track+0x2c/0x50 kasan_save_free_info+0x64/0x108 __kasan_mempool_poison_object+0x148/0x2d4 napi_skb_cache_put+0x5c/0x194 net_tx_action+0x154/0x5b8 handle_softirqs+0x20c/0x60c do_softirq_own_stack+0x6c/0x88 <...> The buggy address belongs to the object at c00000024eb48a00 which belongs to the cache skbuff_head_cache of size 224==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38709 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:loop: Avoid updating block size under exclusive ownerSyzbot came up with a reproducer where a loop device block size ischanged underneath a mounted filesystem. This causes a mismatch betweenthe block device block size and the block size stored in the superblockcausing confusion in various places such as fs/buffer.c. The particularissue triggered by syzbot was a warning in __getblk_slow() due torequested buffer size not matching block device block size.Fix the problem by getting exclusive hold of the loop device to changeits block size. This fails if somebody (such as filesystem) has alreadyan exclusive ownership of the block device and thus prevents modifyingthe loop device under some exclusive owner which doesn't expect it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39759 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix race between quota disable and quota rescan ioctlThere's a race between a task disabling quotas and another running therescan ioctl that can result in a use-after-free of qgroup records fromthe 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 quotaswere already disabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39866 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:fs: writeback: fix use-after-free in __mark_inode_dirty()An use-after-free issue occurred when __mark_inode_dirty() get thebdi_writeback that was in the progress of switching.CPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1......pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __mark_inode_dirty+0x124/0x418lr : __mark_inode_dirty+0x118/0x418sp : ffffffc08c9dbbc0........Call trace: __mark_inode_dirty+0x124/0x418 generic_update_time+0x4c/0x60 file_modified+0xcc/0xd0 ext4_buffered_write_iter+0x58/0x124 ext4_file_write_iter+0x54/0x704 vfs_write+0x1c0/0x308 ksys_write+0x74/0x10c __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x40/0xe4 el0t_64_sync_handler+0x120/0x12c el0t_64_sync+0x194/0x198Root cause is:systemd-random-seed kworker----------------------------------------------------------------------___mark_inode_dirty inode_switch_wbs_work_fn spin_lock(&inode->i_lock); inode_attach_wb locked_inode_to_wb_and_lock_list get inode->i_wb spin_unlock(&inode->i_lock); spin_lock(&wb->list_lock) spin_lock(&inode->i_lock) inode_io_list_move_locked spin_unlock(&wb->list_lock) spin_unlock(&inode->i_lock) spin_lock(&old_wb->list_lock) inode_do_switch_wbs spin_lock(&inode->i_lock) inode->i_wb = new_wb spin_unlock(&inode->i_lock) spin_unlock(&old_wb->list_lock) wb_put_many(old_wb, nr_switched) cgwb_release old wb released wb_wakeup_delayed() accesses wb, then trigger the use-after-free issueFix this race condition by holding inode spinlock untilwb_wakeup_delayed() finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39945 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:cnic: Fix use-after-free bugs in cnic_delete_taskThe original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(),which does not guarantee that the delayed work item 'delete_task' hasfully completed if it was already running. Additionally, the delayed workitem is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() onlyblocks and waits for work items that were already queued to theworkqueue prior to its invocation. Any work items submitted afterflush_workqueue() is called are not included in the set of tasks that theflush operation awaits. This means that after the cyclic work items havefinished executing, a delayed work item may still exist in the workqueue.This leads to use-after-free scenarios where the cnic_dev is deallocatedby cnic_free_dev(), while delete_task remains active and attempt todereference cnic_dev in cnic_delete_task().A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //useReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the cyclic delayed work item is properly canceled and that anyongoing execution of the work item completes before the cnic_dev isdeallocated. Furthermore, since cancel_delayed_work_sync() uses__flush_work(work, true) to synchronously wait for any currentlyexecuting instance of the work item to finish, the flush_workqueue()becomes redundant and should be removed.This bug was identified through static analysis. To reproduce the issueand validate the fix, I simulated the cnic PCI device in QEMU andintroduced intentional delays - such as inserting calls to ssleep()within the cnic_delete_task() function - to increase the likelihoodof triggering the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40121 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5651: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver just ignores and leaves as is, which may lead tounepxected results like OOB access.This patch adds the sanity check and corrects the input mapping to thecertain default value if an invalid value is passed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40154 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: bytcr_rt5640: Fix invalid quirk input mappingWhen an invalid value is passed via quirk option, currentlybytcr_rt5640 driver only shows an error message but leaves as is.This may lead to unepxected results like OOB access.This patch corrects the input mapping to the certain default value ifan invalid value is passed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40323 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Set fb_display[i]->mode to NULL when the mode is releasedRecently, we discovered the following issue through syzkaller:BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0Read of size 4 at addr ff11000001b3c69c by task syz.xxx...Call Trace: dump_stack_lvl+0xab/0xe0 print_address_description.constprop.0+0x2c/0x390 print_report+0xb9/0x280 kasan_report+0xb8/0xf0 fb_mode_is_equal+0x285/0x2f0 fbcon_mode_deleted+0x129/0x180 fb_set_var+0xe7f/0x11d0 do_fb_ioctl+0x6a0/0x750 fb_ioctl+0xe0/0x140 __x64_sys_ioctl+0x193/0x210 do_syscall_64+0x5f/0x9c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eBased on experimentation and analysis, during framebuffer unregistration,only the memory of fb_info->modelist is freed, without setting thecorresponding fb_display[i]->mode to NULL for the freed modes. This leadsto UAF issues during subsequent accesses. Here's an example of reproductionsteps:1. With /dev/fb0 already registered in the system, load a kernel module to register a new device /dev/fb1;2. Set fb1's mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);3. Switch console from fb to VGA (to allow normal rmmod of the ko);4. Unload the kernel module, at this point fb1's modelist is freed, leaving a wild pointer in fb_display[];5. Trigger the bug via system calls through fb0 attempting to delete a mode from fb0.Add a check in do_unregister_framebuffer(): if the mode to be freed existsin fb_display[], set the corresponding mode pointer to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68283 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: replace BUG_ON with bounds check for map->max_osdOSD indexes come from untrusted network packets. Boundary checks areadded to validate these against map->max_osd.[ idryomov: drop BUG_ON in ceph_get_primary_affinity(), minor cosmetic edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68800 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_mr: Fix use-after-free when updating multicast route statsCited commit added a dedicated mutex (instead of RTNL) to protect themulticast route list, so that it will not change while the driverperiodically traverses it in order to update the kernel about multicastroute stats that were queried from the device.One instance of list entry deletion (during route replace) was missedand it can result in a use-after-free [1].Fix by acquiring the mutex before deleting the entry from the list andreleasing it afterwards.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum]Read of size 8 at addr ffff8881523c2fa8 by task kworker/2:5/22043CPU: 2 UID: 0 PID: 22043 Comm: kworker/2:5 Not tainted 6.18.0-rc1-custom-g1a3d6d7cd014 #1 PREEMPT(full)Hardware name: Mellanox Technologies Ltd. MSN2010/SA002610, BIOS 5.6.5 08/24/2017Workqueue: mlxsw_core mlxsw_sp_mr_stats_update [mlxsw_spectrum]Call Trace: dump_stack_lvl+0xba/0x110 print_report+0x174/0x4f5 kasan_report+0xdf/0x110 mlxsw_sp_mr_stats_update+0x4a5/0x540 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:1006 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30 Allocated by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 mlxsw_sp_mr_route_add+0xd8/0x4770 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30Freed by task 29933: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3b/0x70 __kasan_slab_free+0x43/0x70 kfree+0x14e/0x700 mlxsw_sp_mr_route_add+0x2dea/0x4770 drivers/net/ethernet/mellanox/mlxsw/spectrum_mr.c:444 [mlxsw_spectrum] mlxsw_sp_router_fibmr_event_work+0x371/0xad0 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:7965 [mlxsw_spectrum] process_one_work+0x9cc/0x18e0 worker_thread+0x5df/0xe40 kthread+0x3b8/0x730 ret_from_fork+0x3e9/0x560 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71073 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:Input: lkkbd - disable pending work before freeing devicelkkbd_interrupt() schedules lk->tq via schedule_work(), and the workhandler lkkbd_reinit() dereferences the lkkbd structure and itsserio/input_dev fields.lkkbd_disconnect() and error paths in lkkbd_connect() free the lkkbdstructure without preventing the reinit work from being queued againuntil serio_close() returns. This can allow the work handler to runafter the structure has been freed, leading to a potential use-after-free.Use disable_work_sync() instead of cancel_work_sync() to ensure thereinit work cannot be re-queued, and call it both in lkkbd_disconnect()and in lkkbd_connect() error paths after serio_open().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71081 Severity: Moderate CVSS3 score: 6.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: stm32: sai: fix OF node leak on probeThe reference taken to the sync provider OF node when probing theplatform device is currently only dropped if the set_sync() callbackfails during DAI probe.Make sure to drop the reference on platform probe failures (e.g. probedeferral) and on driver unbind.This also avoids a potential use-after-free in case the DAI is everreprobed without first rebinding the platform driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2019-19923 Severity: Moderate CVSS3 score: 6.3

Description: flattenSubquery in select.c in SQLite 3.30.1 mishandles certain uses of SELECT DISTINCT involving a LEFT JOIN in which the right-hand side is a view. This can cause a NULL pointer dereference (or incorrect results).

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2020-15358 Severity: Moderate CVSS3 score: 6.3

Description: In SQLite before 3.32.3, select.c mishandles query-flattener optimization, leading to a multiSelectOrderBy heap overflow because of misuse of transitive properties for constant propagation.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2022-50315 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ata: ahci: Match EM_MAX_SLOTS with SATA_PMP_MAX_PORTSUBSAN complains about array-index-out-of-bounds:[ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41[ 1.980709] kernel: index 15 is out of range for type 'ahci_em_priv [8]'[ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsi_eh_8 Not tainted 5.15.0-25-generic #25-Ubuntu[ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010[ 1.980718] kernel: Call Trace:[ 1.980721] kernel: [ 1.980723] kernel: show_stack+0x52/0x58[ 1.980729] kernel: dump_stack_lvl+0x4a/0x5f[ 1.980734] kernel: dump_stack+0x10/0x12[ 1.980736] kernel: ubsan_epilogue+0x9/0x45[ 1.980739] kernel: __ubsan_handle_out_of_bounds.cold+0x44/0x49[ 1.980742] kernel: ahci_qc_issue+0x166/0x170 [libahci][ 1.980748] kernel: ata_qc_issue+0x135/0x240[ 1.980752] kernel: ata_exec_internal_sg+0x2c4/0x580[ 1.980754] kernel: ? vprintk_default+0x1d/0x20[ 1.980759] kernel: ata_exec_internal+0x67/0xa0[ 1.980762] kernel: sata_pmp_read+0x8d/0xc0[ 1.980765] kernel: sata_pmp_read_gscr+0x3c/0x90[ 1.980768] kernel: sata_pmp_attach+0x8b/0x310[ 1.980771] kernel: ata_eh_revalidate_and_attach+0x28c/0x4b0[ 1.980775] kernel: ata_eh_recover+0x6b6/0xb30[ 1.980778] kernel: ? ahci_do_hardreset+0x180/0x180 [libahci][ 1.980783] kernel: ? ahci_stop_engine+0xb0/0xb0 [libahci][ 1.980787] kernel: ? ahci_do_softreset+0x290/0x290 [libahci][ 1.980792] kernel: ? trace_event_raw_event_ata_eh_link_autopsy_qc+0xe0/0xe0[ 1.980795] kernel: sata_pmp_eh_recover.isra.0+0x214/0x560[ 1.980799] kernel: sata_pmp_error_handler+0x23/0x40[ 1.980802] kernel: ahci_error_handler+0x43/0x80 [libahci][ 1.980806] kernel: ata_scsi_port_error_handler+0x2b1/0x600[ 1.980810] kernel: ata_scsi_error+0x9c/0xd0[ 1.980813] kernel: scsi_error_handler+0xa1/0x180[ 1.980817] kernel: ? scsi_unjam_host+0x1c0/0x1c0[ 1.980820] kernel: kthread+0x12a/0x150[ 1.980823] kernel: ? set_kthread_struct+0x50/0x50[ 1.980826] kernel: ret_from_fork+0x22/0x30[ 1.980831] kernel: This happens because sata_pmp_init_links() initialize link->pmp up toSATA_PMP_MAX_PORTS while em_priv is declared as 8 elements array.I can't find the maximum Enclosure Management ports specified in AHCIspec v1.3.1, but "12.2.1 LED message type" states that "Port MultiplierInformation" can utilize 4 bits, which implies it can support up to 16ports. Hence, use SATA_PMP_MAX_PORTS as EM_MAX_SLOTS to resolve theissue.BugLink: https://bugs.launchpad.net/bugs/1970074

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50542 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: si470x: Fix use-after-free in si470x_int_in_callback()syzbot reported use-after-free in si470x_int_in_callback() [1]. Thisindicates that urb->context, which contains struct si470x_deviceobject, is freed when si470x_int_in_callback() is called.The cause of this issue is that si470x_int_in_callback() is called forfreed urb.si470x_usb_driver_probe() calls si470x_start_usb(), which then callsusb_submit_urb() and si470x_start(). If si470x_start_usb() fails,si470x_usb_driver_probe() doesn't kill urb, but it just frees structsi470x_device object, as depicted below:si470x_usb_driver_probe() ... si470x_start_usb() ... usb_submit_urb() retval = si470x_start() return retval if (retval < 0) free struct si470x_device object, but don't kill urbThis patch fixes this issue by killing urb when si470x_start_usb()fails and urb is submitted. If si470x_start_usb() fails and urb isnot submitted, i.e. submitting usb fails, it just frees structsi470x_device object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50570 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:platform/chrome: fix memory corruption in ioctlIf "s_mem.bytes" is larger than the buffer size it leads to memorycorruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50720 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:x86/apic: Don't disable x2APIC if lockedThe APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC(or x2APIC). X2APIC mode is mostly compatible with legacy APIC, butit disables the memory-mapped APIC interface in favor of one that usesMSRs. The APIC mode is controlled by the EXT bit in the APIC MSR.The MMIO/xAPIC interface has some problems, most notably the APIC LEAK[1]. This bug allows an attacker to use the APIC MMIO interface toextract data from the SGX enclave.Introduce support for a new feature that will allow the BIOS to lockthe APIC in x2APIC mode. If the APIC is locked in x2APIC mode and thekernel tries to disable the APIC or revert to legacy APIC mode a GPfault will occur.Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handlethe new locked mode when the LEGACY_XAPIC_DISABLED bit is set bypreventing the kernel from trying to disable the x2APIC.On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX areenabled the LEGACY_XAPIC_DISABLED will be set by the BIOS. Iflegacy APIC is required, then it SGX and TDX need to be disabled in theBIOS.[1]: https://aepicleak.com/aepicleak.pdf

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50764 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/sit: use DEV_STATS_INC() to avoid data-racessyzbot/KCSAN reported that multiple cpus are updating dev->stats.tx_errorconcurrently.This is because sit tunnels are NETIF_F_LLTX, meaning their ndo_start_xmit()is not protected by a spinlock.While original KCSAN report was about tx path, rx path has the same issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53623 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/swap: fix swap_info_struct race between swapoff and get_swap_pages()The si->lock must be held when deleting the si from the available list. Otherwise, another thread can re-add the si to the available list, whichcan lead to memory corruption. The only place we have found where thishappens is in the swapoff path. This case can be described as below:core 0 core 1swapoffdel_from_avail_list(si) waitingtry lock si->lock acquire swap_avail_lock and re-add si into swap_avail_headacquire si->lock but missing si already being added again, and continuingto clear SWP_WRITEOK, etc.It can be easily found that a massive warning messages can be triggeredinside get_swap_pages() by some special cases, for example, we callmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,run much swapon-swapoff operations (e.g. stress-ng-swap).However, in the worst case, panic can be caused by the above scene. Inswapoff(), the memory used by si could be kept in swap_info[] afterturning off a swap. This means memory corruption will not be causedimmediately until allocated and reset for a new swap in the swapon path. A panic message caused: (with CONFIG_PLIST_DEBUG enabled)------------[ cut here ]------------top: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451aprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8dnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451aWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70Modules linked in: rfkill(E) crct10dif_ce(E)...CPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+Hardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)pc : plist_check_prev_next_node+0x50/0x70lr : plist_check_prev_next_node+0x50/0x70sp : ffff0018009d3c30x29: ffff0018009d3c40 x28: ffff800011b32a98x27: 0000000000000000 x26: ffff001803908000x25: ffff8000128ea088 x24: ffff800011b32a48x23: 0000000000000028 x22: ffff001800875c00x21: ffff800010f9e520 x20: ffff001800875c00x19: ffff001800fdc6e0 x18: 0000000000000030x17: 0000000000000000 x16: 0000000000000000x15: 0736076307640766 x14: 0730073007380731x13: 0736076307640766 x12: 0730073007380731x11: 000000000004058d x10: 0000000085a85b76x9 : ffff8000101436e4 x8 : ffff800011c8ce08x7 : 0000000000000000 x6 : 0000000000000001x5 : ffff0017df9ed338 x4 : 0000000000000001x3 : ffff8017ce62a000 x2 : ffff0017df9ed340x1 : 0000000000000000 x0 : 0000000000000000Call trace: plist_check_prev_next_node+0x50/0x70 plist_check_head+0x80/0xf0 plist_add+0x28/0x140 add_to_avail_list+0x9c/0xf0 _enable_swap_info+0x78/0xb4 __do_sys_swapon+0x918/0xa10 __arm64_sys_swapon+0x20/0x30 el0_svc_common+0x8c/0x220 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180irq event stamp: 2082270Now, si->lock locked before calling 'del_from_avail_list()' to make sureother thread see the si had been deleted and SWP_WRITEOK cleared together,will not reinsert again.This problem exists in versions after stable 5.10.y.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53626 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix possible double unlock when moving a directory

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53695 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Detect system inodes linked into directory hierarchyWhen UDF filesystem is corrupted, hidden system inodes can be linkedinto directory hierarchy which is an avenue for further seriouscorruption of the filesystem and kernel confusion as noticed by syzbotfuzzed images. Refuse to access system inodes linked into directoryhierarchy and vice versa.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54068 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix to call f2fs_wait_on_page_writeback() in f2fs_write_raw_pages()BUG_ON() will be triggered when writing files concurrently,because the same page is writtenback multiple times.1597 void folio_end_writeback(struct folio *folio)1598 { ......1618 if (!__folio_end_writeback(folio))1619 BUG(); ......1625 }kernel BUG at mm/filemap.c:1619!Call Trace: f2fs_write_end_io+0x1a0/0x370 blk_update_request+0x6c/0x410 blk_mq_end_request+0x15/0x130 blk_complete_reqs+0x3c/0x50 __do_softirq+0xb8/0x29b ? sort_range+0x20/0x20 run_ksoftirqd+0x19/0x20 smpboot_thread_fn+0x10b/0x1d0 kthread+0xde/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 Below is the concurrency scenario:[Process A] [Process B] [Process C]f2fs_write_raw_pages() - redirty_page_for_writepage() - unlock page() f2fs_do_write_data_page() - lock_page() - clear_page_dirty_for_io() - set_page_writeback() [1st writeback] ..... - unlock page() generic_perform_write() - f2fs_write_begin() - wait_for_stable_page() - f2fs_write_end() - set_page_dirty() - lock_page() - f2fs_do_write_data_page() - set_page_writeback() [2st writeback]This problem was introduced by the previous commit 7377e853967b ("f2fs:compress: fix potential deadlock of compress file"). All pagelocks werereleased in f2fs_write_raw_pages(), but whether the page wasin the writeback state was ignored in the subsequent writing process.Let's fix it by waiting for the page to writeback before writing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54128 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: drop peer group ids under namespace lockWhen cleaning up peer group ids in the failure path we need to make sureto hold on to the namespace lock. Otherwise another thread might justturn the mount from a shared into a non-shared mount concurrently.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54137 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/type1: fix cap_migration information leakFix an information leak where an uninitialized hole in structvfio_iommu_type1_info_cap_migration on the stack is exposed to userspace.The definition of struct vfio_iommu_type1_info_cap_migration contains a hole asshown in this pahole(1) output: struct vfio_iommu_type1_info_cap_migration { struct vfio_info_cap_header header; /* 0 8 */ __u32 flags; /* 8 4 */ /* XXX 4 bytes hole, try to pack */ __u64 pgsize_bitmap; /* 16 8 */ __u64 max_dirty_bitmap_size; /* 24 8 */ /* size: 32, cachelines: 1, members: 4 */ /* sum members: 28, holes: 1, sum holes: 4 */ /* last cacheline: 32 bytes */ };The cap_mig variable is filled in without initializing the hole: static int vfio_iommu_migration_build_caps(struct vfio_iommu *iommu, struct vfio_info_cap *caps) { struct vfio_iommu_type1_info_cap_migration cap_mig; cap_mig.header.id = VFIO_IOMMU_TYPE1_INFO_CAP_MIGRATION; cap_mig.header.version = 1; cap_mig.flags = 0; /* support minimum pgsize */ cap_mig.pgsize_bitmap = (size_t)1 << __ffs(iommu->pgsize_bitmap); cap_mig.max_dirty_bitmap_size = DIRTY_BITMAP_SIZE_MAX; return vfio_info_add_capability(caps, &cap_mig.header, sizeof(cap_mig)); }The structure is then copied to a temporary location on the heap. At this pointit's already too late and ioctl(VFIO_IOMMU_GET_INFO) copies it to userspacelater: int vfio_info_add_capability(struct vfio_info_cap *caps, struct vfio_info_cap_header *cap, size_t size) { struct vfio_info_cap_header *header; header = vfio_info_cap_add(caps, size, cap->id, cap->version); if (IS_ERR(header)) return PTR_ERR(header); memcpy(header + 1, cap + 1, size - sizeof(*header)); return 0; }This issue was found by code inspection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54200 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: always release netdev hooks from notifierThis reverts "netfilter: nf_tables: skip netdev events generated on netns removal".The problem is that when a veth device is released, the veth releasecallback will also queue the peer netns device for removal.Its possible that the peer netns is also slated for removal. In thiscase, the device memory is already released before the pre_exit hook ofthe peer netns runs:BUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0Read of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45Workqueue: netns cleanup_netCall Trace: nf_hook_entry_head+0x1b8/0x1d0 __nf_unregister_net_hook+0x76/0x510 nft_netdev_unregister_hooks+0xa0/0x220 __nft_release_hook+0x184/0x490 nf_tables_pre_exit_net+0x12f/0x1b0 ..Order is:1. First netns is released, veth_dellink() queues peer netns device for removal2. peer netns is queued for removal3. peer netns device is released, unreg event is triggered4. unreg event is ignored because netns is going down5. pre_exit hook calls nft_netdev_unregister_hooks but device memory might be free'd already.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54257 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: macb: fix a memory corruption in extended buffer descriptor modeFor quite some time we were chasing a bug which looked like a suddenpermanent failure of networking and mmc on some of our devices.The bug was very sensitive to any software changes and even more toany kernel debug options.Finally we got a setup where the problem was reproducible withCONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:[ 16.992082] ------------[ cut here ]------------[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes][ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900[ 17.018977] Modules linked in: xxxxx[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28[ 17.045345] Hardware name: xxxxx[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)[ 17.054322] pc : check_unmap+0x6a0/0x900[ 17.058243] lr : check_unmap+0x6a0/0x900[ 17.062163] sp : ffffffc010003c40[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010[ 17.097343] x17: 0000000000000000 x16: 0000000000000000[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720[ 17.107959] x13: 0720072007200720 x12: 0720072007200720[ 17.113261] x11: 0720072007200720 x10: 0720072007200720[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000[ 17.145082] Call trace:[ 17.147524] check_unmap+0x6a0/0x900[ 17.151091] debug_dma_unmap_page+0x88/0x90[ 17.155266] gem_rx+0x114/0x2f0[ 17.158396] macb_poll+0x58/0x100[ 17.161705] net_rx_action+0x118/0x400[ 17.165445] __do_softirq+0x138/0x36c[ 17.169100] irq_exit+0x98/0xc0[ 17.172234] __handle_domain_irq+0x64/0xc0[ 17.176320] gic_handle_irq+0x5c/0xc0[ 17.179974] el1_irq+0xb8/0x140[ 17.183109] xiic_process+0x5c/0xe30[ 17.186677] irq_thread_fn+0x28/0x90[ 17.190244] irq_thread+0x208/0x2a0[ 17.193724] kthread+0x130/0x140[ 17.196945] ret_from_fork+0x10/0x20[ 17.200510] ---[ end trace 7240980785f81d6f ]---[ 237.021490] ------------[ cut here ]------------[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240[ 237.041802] Modules linked in: xxxxx[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28[ 237.068941] Hardware name: xxxxx[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)[ 237.077900] pc : add_dma_entry+0x214/0x240[ 237.081986] lr : add_dma_entry+0x214/0x240[ 237.086072] sp : ffffffc010003c30[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0[ 237.099987] x25: 0000000000000002 x24: 0000000000000000[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010[ 237.121201] x17: 0000000000000000 x16: 0000000000000000[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720[ 237.131807] x13: 0720072007200720 x12: 0720072007200720[ 237.137111] x11: 0720072007200720 x10: 0720072007200720[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000[ 237.15302---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54324 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix a race condition in retrieve_depsThere's a race condition in the multipath target when retrieve_depsraces with multipath_message calling dm_get_device and dm_put_device.retrieve_deps walks the list of open devices without holding any lockbut multipath may add or remove devices to the list while it isrunning. The end result may be memory corruption or use-after-freememory access.See this description of a UAF with multipath_message():https://listman.redhat.com/archives/dm-devel/2022-October/052373.htmlFix this bug by introducing a new rw semaphore "devices_lock". We grabdevices_lock for read in retrieve_deps and we grab it for write indm_get_device and dm_put_device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-24861 Severity: Moderate CVSS3 score: 6.3

Description: A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26988 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:init/main.c: Fix potential static_command_line memory overflowWe allocate memory of size 'xlen + strlen(boot_command_line) + 1' forstatic_command_line, but the strings copied into static_command_line areextra_command_line and command_line, rather than extra_command_line andboot_command_line.When strlen(command_line) > strlen(boot_command_line), static_command_linewill overflow.This patch just recovers strlen(command_line) which was miss-consolidatedwith strlen(boot_command_line) in the commit f5c7310ac73e ("init/main: addchecks for the return value of memblock_alloc*()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38659 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:enic: Validate length of nl attributes in enic_set_vf_portenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILEis of length PORT_PROFILE_MAX and that the nl attributesIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.These attributes are validated (in the function do_setlink in rtnetlink.c)using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILEas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY andIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validationusing the policy is for the max size of the attributes and not on exactsize so the length of these attributes might be less than the sizes thatenic_set_vf_port expects. This might cause an out of bandsread access in the memcpys of the data of theseattributes in enic_set_vf_port.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39508 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: Use set_bit() and test_bit() at worker->flagsUtilize set_bit() and test_bit() on worker->flags within io_uring/io-wqto address potential data races.The structure io_worker->flags may be accessed through various datapaths, leading to concurrency issues. When KCSAN is enabled, it revealsdata races occurring in io_worker_handle_work andio_wq_activate_free_worker functions. BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28: io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569) io_wq_worker (io_uring/io-wq.c:?) read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5: io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285) io_wq_enqueue (io_uring/io-wq.c:947) io_queue_iowq (io_uring/io_uring.c:524) io_req_task_submit (io_uring/io_uring.c:1511) io_handle_tw_list (io_uring/io_uring.c:1198)Line numbers against commit 18daea77cca6 ("Merge tag 'for-linus' ofgit://git.kernel.org/pub/scm/virt/kvm/kvm").These races involve writes and reads to the same memory location bydifferent tasks running on different CPUs. To mitigate this, refactorthe code to use atomic operations such as set_bit(), test_bit(), andclear_bit() instead of basic "and" and "or" operations. This ensuresthread-safe manipulation of worker flags.Also, move `create_index` to avoid holes in the structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41020 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:filelock: Fix fcntl/close race recovery compat pathWhen I wrote commit 3cad1bc01041 ("filelock: Remove locks reliably whenfcntl/close race is detected"), I missed that there are two copies of thecode I was patching: The normal version, and the version for 64-bit offsetson 32-bit kernels.Thanks to Greg KH for stumbling over this while doing the stablebackport...Apply exactly the same fix to the compat path for 32-bit kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41044 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: reject claimed-as-LCP but actually malformed packetsSince 'ppp_async_encode()' assumes valid LCP packets (with codefrom 1 to 7 inclusive), add 'ppp_check_packet()' to ensure thatLCP packet has an actual body beyond PPP_LCP header bytes, andreject claimed-as-LCP but actually malformed data otherwise.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42084 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures. As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47408 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check smcd_v2_ext_offset when receiving proposal msgWhen receiving proposal msg in server, the field smcd_v2_ext_offset inproposal msg is from the remote client and can not be fully trusted.Once the value of smcd_v2_ext_offset exceed the max value, there hasthe chance to access wrong address, and crash may happen.This patch checks the value of smcd_v2_ext_offset before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49568 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check v2_ext_offset/eid_cnt/ism_gid_cnt when receiving proposal msgWhen receiving proposal msg in server, the fields v2_ext_offset/eid_cnt/ism_gid_cnt in proposal msg are from the remote clientand can not be fully trusted. Especially the field v2_ext_offset,once exceed the max value, there has the chance to access wrongaddress, and crash may happen.This patch checks the fields v2_ext_offset/eid_cnt/ism_gid_cntbefore using them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49571 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: check iparea_offset and ipv6_prefixes_cnt when receiving proposal msgWhen receiving proposal msg in server, the field iparea_offsetand the field ipv6_prefixes_cnt in proposal msg are from theremote client and can not be fully trusted. Especially thefield iparea_offset, once exceed the max value, there has thechance to access wrong address, and crash may happen.This patch checks iparea_offset and ipv6_prefixes_cnt before using them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50063 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tail call between progs attached to different hooksbpf progs can be attached to kernel functions, and the attached functionscan take different parameters or return different return values. Ifprog attached to one kernel function tail calls prog attached to anotherkernel function, the ctx access or return value verification could bebypassed.For example, if prog1 is attached to func1 which takes only 1 parameterand prog2 is attached to func2 which takes two parameters. Since verifierassumes the bpf ctx passed to prog2 is constructed based on func2'sprototype, verifier allows prog2 to access the second parameter fromthe bpf ctx passed to it. The problem is that verifier does not preventprog1 from passing its bpf ctx to prog2 via tail call. In this case,the bpf ctx passed to prog2 is constructed from func1 instead of func2,that is, the assumption for ctx access verification is bypassed.Another example, if BPF LSM prog1 is attached to hook file_alloc_security,and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifierknows the return value rules for these two hooks, e.g. it is legal forbpf_lsm_audit_rule_known to return positive number 1, and it is illegalfor file_alloc_security to return positive number. So verifier allowsprog2 to return positive number 1, but does not allow prog1 to returnpositive number. The problem is that verifier does not prevent prog1from calling prog2 via tail call. In this case, prog2's return value 1will be used as the return value for prog1's hook file_alloc_security.That is, the return value rule is bypassed.This patch adds restriction for tail call to prevent such bypasses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50135 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix race condition between reset and nvme_dev_disable()nvme_dev_disable() modifies the dev->online_queues field, thereforenvme_pci_update_nr_queues() should avoid racing against it, otherwisewe could end up passing invalid values to blk_mq_update_nr_hw_queues(). WARNING: CPU: 39 PID: 61303 at drivers/pci/msi/api.c:347 pci_irq_get_affinity+0x187/0x210 Workqueue: nvme-reset-wq nvme_reset_work [nvme] RIP: 0010:pci_irq_get_affinity+0x187/0x210 Call Trace: ? blk_mq_pci_map_queues+0x87/0x3c0 ? pci_irq_get_affinity+0x187/0x210 blk_mq_pci_map_queues+0x87/0x3c0 nvme_pci_map_queues+0x189/0x460 [nvme] blk_mq_update_nr_hw_queues+0x2a/0x40 nvme_reset_work+0x1be/0x2a0 [nvme]Fix the bug by locking the shutdown_lock mutex before usingdev->online_queues. Give up if nvme_dev_disable() is running or ifit has been executed already.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50142 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: validate new SA's prefixlen using SA family when sel.family is unsetThis expands the validation introduced in commit 07bf7908950a ("xfrm:Validate address prefix lengths in the xfrm selector.")syzbot created an SA with usersa.sel.family = AF_UNSPEC usersa.sel.prefixlen_s = 128 usersa.family = AF_INETBecause of the AF_UNSPEC selector, verify_newsa_info doesn't putlimits on prefixlen_{s,d}. But then copy_from_user_state setsx->sel.family to usersa.family (AF_INET). Do the same conversion inverify_newsa_info before validating prefixlen_{s,d}, since that's howprefixlen is going to be used later on.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50278 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: fix potential out-of-bounds access on the first resumeOut-of-bounds access occurs if the fast device is expanded unexpectedlybefore the first-time resume of the cache table. This happens becauseexpanding the fast device requires reloading the cache table forcache_create to allocate new in-core data structures that fit the newsize, and the check in cache_preresume is not performed during thefirst resume, leading to the issue.Reproduce steps:1. prepare component devices:dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate.dmsetup create cache --notabledmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192"dmsetup resume cdatadmsetup resume cache3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40:dmsetup suspend cacheKASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8Fix by checking the size change on the first resume.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53088 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix race condition by adding filter's intermediate sync stateFix a race condition in the i40e driver that leads to MAC/VLAN filtersbecoming corrupted and leaking. Address the issue that occurs underheavy load when multiple threads are concurrently modifying MAC/VLANfilters by setting mac and port VLAN.1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan().2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac().3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption.Reproduction steps:1. Spawn multiple VFs.2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host.3. Observe errors in dmesg:"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, please set promiscuous on manually for VF XX".Exact code for stable reproduction Intel can't open-source now.The fix involves implementing a new intermediate filter state,I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.These filters cannot be deleted from the hash list directly butmust be removed using the full process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53147 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix out-of-bounds access of directory entriesIn the case of the directory size is greater than or equal tothe cluster size, if start_clu becomes an EOF cluster(an invalidcluster) due to file system corruption, then the directory entrywhere ei->hint_femp.eidx hint is outside the directory, resultingin an out-of-bounds access, which may cause further file systemcorruption.This commit adds a check for start_clu, if it is an invalid cluster,the file or directory will be treated as empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57900 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ila: serialize calls to nf_register_net_hooks()syzbot found a race in ila_add_mapping() [1]commit 031ae72825ce ("ila: call nf_unregister_net_hooks() sooner")attempted to fix a similar issue.Looking at the syzbot repro, we have concurrent ILA_CMD_ADD commands.Add a mutex to make sure at most one thread is calling nf_register_net_hooks().[1] BUG: KASAN: slab-use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: slab-use-after-free in __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604Read of size 4 at addr ffff888028f40008 by task dhcpcd/5501CPU: 1 UID: 0 PID: 5501 Comm: dhcpcd Not tainted 6.13.0-rc4-syzkaller-00054-gd6ef8b40d075 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xc3/0x620 mm/kasan/report.c:489 kasan_report+0xd9/0x110 mm/kasan/report.c:602 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup.constprop.0+0x426/0x550 include/linux/rhashtable.h:604 rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast include/linux/rhashtable.h:672 [inline] ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:127 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1ee/0x620 net/ipv6/ila/ila_xlat.c:185 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xbb/0x200 net/netfilter/core.c:626 nf_hook.constprop.0+0x42e/0x750 include/linux/netfilter.h:269 NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0xa4/0x680 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x12e/0x1e0 net/core/dev.c:5672 __netif_receive_skb+0x1d/0x160 net/core/dev.c:5785 process_backlog+0x443/0x15f0 net/core/dev.c:6117 __napi_poll.constprop.0+0xb7/0x550 net/core/dev.c:6883 napi_poll net/core/dev.c:6952 [inline] net_rx_action+0xa94/0x1010 net/core/dev.c:7074 handle_softirqs+0x213/0x8f0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0x109/0x170 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0xa4/0xc0 arch/x86/kernel/apic/apic.c:1049

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-14017 Severity: Moderate CVSS3 score: 6.3

Description: When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl,changing TLS options in one thread would inadvertently change them globallyand therefore possibly also affect other concurrently setup transfers.Disabling certificate verification for a specific transfer couldunintentionally disable the feature for other threads as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-21673 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix double free of TCP_Server_Info::hostnameWhen shutting down the server in cifs_put_tcp_session(), cifsd threadmight be reconnecting to multiple DFS targets before it realizes itshould exit the loop, so @server->hostname can't be freed as long ascifsd thread isn't done. Otherwise the following can happen: RIP: 0010:__slab_free+0x223/0x3c0 Code: 5e 41 5f c3 cc cc cc cc 4c 89 de 4c 89 cf 44 89 44 24 08 4c 89 1c 24 e8 fb cf 8e 00 44 8b 44 24 08 4c 8b 1c 24 e9 5f fe ff ff <0f> 0b 41 f7 45 08 00 0d 21 00 0f 85 2d ff ff ff e9 1f ff ff ff 80 RSP: 0018:ffffb26180dbfd08 EFLAGS: 00010246 RAX: ffff8ea34728e510 RBX: ffff8ea34728e500 RCX: 0000000000800068 RDX: 0000000000800068 RSI: 0000000000000000 RDI: ffff8ea340042400 RBP: ffffe112041ca380 R08: 0000000000000001 R09: 0000000000000000 R10: 6170732e31303000 R11: 70726f632e786563 R12: ffff8ea34728e500 R13: ffff8ea340042400 R14: ffff8ea34728e500 R15: 0000000000800068 FS: 0000000000000000(0000) GS:ffff8ea66fd80000(0000) 000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc25376080 CR3: 000000012a2ba001 CR4: PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __reconnect_target_unlocked+0x3e/0x160 [cifs] ? __die_body.cold+0x8/0xd ? die+0x2b/0x50 ? do_trap+0xce/0x120 ? __slab_free+0x223/0x3c0 ? do_error_trap+0x65/0x80 ? __slab_free+0x223/0x3c0 ? exc_invalid_op+0x4e/0x70 ? __slab_free+0x223/0x3c0 ? asm_exc_invalid_op+0x16/0x20 ? __slab_free+0x223/0x3c0 ? extract_hostname+0x5c/0xa0 [cifs] ? extract_hostname+0x5c/0xa0 [cifs] ? __kmalloc+0x4b/0x140 __reconnect_target_unlocked+0x3e/0x160 [cifs] reconnect_dfs_server+0x145/0x430 [cifs] cifs_handle_standard+0x1ad/0x1d0 [cifs] cifs_demultiplex_thread+0x592/0x730 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21738 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ata: libata-sff: Ensure that we cannot write outside the allocated bufferreveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_lenset to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set toATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() towrite outside the allocated buffer, overwriting random memory.While a ATA device is supposed to abort a ATA_NOP command, there does seemto be a bug either in libata-sff or QEMU, where either this status is notset, or the status is cleared before read by ata_sff_hsm_move().Anyway, that is most likely a separate bug.Looking at __atapi_pio_bytes(), it already has a safety check to ensurethat __atapi_pio_bytes() cannot write outside the allocated buffer.Add a similar check to ata_pio_sector(), such that also ata_pio_sector()cannot write outside the allocated buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23133 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: update channel list in reg notifier instead reg workerCurrently when ath11k gets a new channel list, it will be processedaccording to the following steps:1. update new channel list to cfg80211 and queue reg_work.2. cfg80211 handles new channel list during reg_work.3. update cfg80211's handled channel list to firmware byath11k_reg_update_chan_list().But ath11k will immediately execute step 3 after reg_work is justqueued. Since step 2 is asynchronous, cfg80211 may not have completedhandling the new channel list, which may leading to an out-of-boundswrite error:BUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_listCall Trace: ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k] kfree+0x109/0x3a0 ath11k_regd_update+0x1cf/0x350 [ath11k] ath11k_regd_update_work+0x14/0x20 [ath11k] process_one_work+0xe35/0x14c0Should ensure step 2 is completely done before executing step 3. ThusWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,cfg80211 will notify ath11k after step 2 is done.So enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 willnotify ath11k after step 2 is done. At this time, there will be noKASAN bug during the execution of the step 3.[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37954 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Avoid race in open_cached_dir with lease breaksA pre-existing valid cfid returned from find_or_create_cached_dir mightrace with a lease break, meaning open_cached_dir doesn't consider itvalid, and thinks it's newly-constructed. This leaks a dentry referenceif the allocation occurs before the queued lease break work runs.Avoid the race by extending holding the cfid_list_lock acrossfind_or_create_cached_dir and when the result is checked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38004 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: add locking for bcm_op runtime updatesThe CAN broadcast manager (CAN BCM) can send a sequence of CAN frames viahrtimer. The content and also the length of the sequence can be changedresp reduced at runtime where the 'currframe' counter is then set to zero.Although this appeared to be a safe operation the updates of 'currframe'can be triggered from user space and hrtimer context in bcm_can_tx().Anderson Nascimento created a proof of concept that triggered a KASANslab-out-of-bounds read access which can be prevented with a spin_lock_bh.At the rework of bcm_can_tx() the 'count' variable has been moved intothe protected section as this variable can be modified from both contextstoo.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38064 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:virtio: break and reset virtio devices on device_shutdown()Hongyu reported a hang on kexec in a VM. QEMU reported invalid memoryaccesses during the hang. Invalid read at addr 0x102877002, size 2, region '(null)', reason: rejected Invalid write at addr 0x102877A44, size 2, region '(null)', reason: rejected ...It was traced down to virtio-console. Kexec works fine if virtio-consoleis not in use.The issue is that virtio-console continues to write to the MMIO even afterunderlying virtio-pci device is reset.Additionally, Eric noticed that IOMMUs are reset before devices, ifdevices are not reset on shutdown they continue to poke at guest memoryand get errors from the IOMMU. Some devices get wedged then.The problem can be solved by breaking all virtio devices on virtiobus shutdown, then resetting them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38300 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():1] If dma_map_sg() fails for areq->dst, the device driver would try to free DMA memory it has not allocated in the first place. To fix this, on the "theend_sgs" error path, call dma unmap only if the corresponding dma map was successful.2] If the dma_map_single() call for the IV fails, the device driver would try to free an invalid DMA memory address on the "theend_iv" path: ------------[ cut here ]------------ DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90 Modules linked in: skcipher_example(O+) CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT Tainted: [O]=OOT_MODULE Hardware name: OrangePi Zero2 (DT) pc : check_unmap+0x123c/0x1b90 lr : check_unmap+0x123c/0x1b90 ... Call trace: check_unmap+0x123c/0x1b90 (P) debug_dma_unmap_page+0xac/0xc0 dma_unmap_page_attrs+0x1f4/0x5fc sun8i_ce_cipher_do_one+0x1bd4/0x1f40 crypto_pump_work+0x334/0x6e0 kthread_worker_fn+0x21c/0x438 kthread+0x374/0x664 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]---To fix this, check for !dma_mapping_error() before callingdma_unmap_single() on the "theend_iv" path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38365 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a race between renames and directory loggingWe have a race between a rename and directory inode logging that if ithappens and we crash/power fail before the rename completes, the next timethe filesystem is mounted, the log replay code will end up deleting thefile that was being renamed.This is best explained following a step by step analysis of an interleavingof steps that lead into this situation.Consider the initial conditions:1) We are at transaction N;2) We have directories A and B created in a past transaction (< N);3) We have inode X corresponding to a file that has 2 hardlinks, one in directory A and the other in directory B, so we'll name them as "A/foo_link1" and "B/foo_link2". Both hard links were persisted in a past transaction (< N);4) We have inode Y corresponding to a file that as a single hard link and is located in directory A, we'll name it as "A/bar". This file was also persisted in a past transaction (< N).The steps leading to a file loss are the following and for all of them weare under transaction N: 1) Link "A/foo_link1" is removed, so inode's X last_unlink_trans field is updated to N, through btrfs_unlink() -> btrfs_record_unlink_dir(); 2) Task A starts a rename for inode Y, with the goal of renaming from "A/bar" to "A/baz", so we enter btrfs_rename(); 3) Task A inserts the new BTRFS_INODE_REF_KEY for inode Y by calling btrfs_insert_inode_ref(); 4) Because the rename happens in the same directory, we don't set the last_unlink_trans field of directoty A's inode to the current transaction id, that is, we don't cal btrfs_record_unlink_dir(); 5) Task A then removes the entries from directory A (BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items) when calling __btrfs_unlink_inode() (actually the dir index item is added as a delayed item, but the effect is the same); 6) Now before task A adds the new entry "A/baz" to directory A by calling btrfs_add_link(), another task, task B is logging inode X; 7) Task B starts a fsync of inode X and after logging inode X, at btrfs_log_inode_parent() it calls btrfs_log_all_parents(), since inode X has a last_unlink_trans value of N, set at in step 1; 8) At btrfs_log_all_parents() we search for all parent directories of inode X using the commit root, so we find directories A and B and log them. Bu when logging direct A, we don't have a dir index item for inode Y anymore, neither the old name "A/bar" nor for the new name "A/baz" since the rename has deleted the old name but has not yet inserted the new name - task A hasn't called yet btrfs_add_link() to do that. Note that logging directory A doesn't fallback to a transaction commit because its last_unlink_trans has a lower value than the current transaction's id (see step 4); 9) Task B finishes logging directories A and B and gets back to btrfs_sync_file() where it calls btrfs_sync_log() to persist the log tree;10) Task B successfully persisted the log tree, btrfs_sync_log() completed with success, and a power failure happened. We have a log tree without any directory entry for inode Y, so the log replay code deletes the entry for inode Y, name "A/bar", from the subvolume tree since it doesn't exist in the log tree and the log tree is authorative for its index (we logged a BTRFS_DIR_LOG_INDEX_KEY item that covers the index range for the dentry that corresponds to "A/bar"). Since there's no other hard link for inode Y and the log replay code deletes the name "A/bar", the file is lost.The issue wouldn't happen if task B synced the log only after task Acalled btrfs_log_new_name(), which would update the log with the new namefor inode Y ("A/bar").Fix this by pinning the log root during renames before removing the olddirectory entry, and unpinning af---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38714 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()The hfsplus_bnode_read() method can trigger the issue:[ 174.852007][ T9784] ==================================================================[ 174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360[ 174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784[ 174.854059][ T9784][ 174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)[ 174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 174.854286][ T9784] Call Trace:[ 174.854289][ T9784] [ 174.854292][ T9784] dump_stack_lvl+0x10e/0x1f0[ 174.854305][ T9784] print_report+0xd0/0x660[ 174.854315][ T9784] ? __virt_addr_valid+0x81/0x610[ 174.854323][ T9784] ? __phys_addr+0xe8/0x180[ 174.854330][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854337][ T9784] kasan_report+0xc6/0x100[ 174.854346][ T9784] ? hfsplus_bnode_read+0x2f4/0x360[ 174.854354][ T9784] hfsplus_bnode_read+0x2f4/0x360[ 174.854362][ T9784] hfsplus_bnode_dump+0x2ec/0x380[ 174.854370][ T9784] ? __pfx_hfsplus_bnode_dump+0x10/0x10[ 174.854377][ T9784] ? hfsplus_bnode_write_u16+0x83/0xb0[ 174.854385][ T9784] ? srcu_gp_start+0xd0/0x310[ 174.854393][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854402][ T9784] hfsplus_brec_remove+0x3d2/0x4e0[ 174.854411][ T9784] __hfsplus_delete_attr+0x290/0x3a0[ 174.854419][ T9784] ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10[ 174.854427][ T9784] ? __pfx___hfsplus_delete_attr+0x10/0x10[ 174.854436][ T9784] ? __asan_memset+0x23/0x50[ 174.854450][ T9784] hfsplus_delete_all_attrs+0x262/0x320[ 174.854459][ T9784] ? __pfx_hfsplus_delete_all_attrs+0x10/0x10[ 174.854469][ T9784] ? rcu_is_watching+0x12/0xc0[ 174.854476][ T9784] ? __mark_inode_dirty+0x29e/0xe40[ 174.854483][ T9784] hfsplus_delete_cat+0x845/0xde0[ 174.854493][ T9784] ? __pfx_hfsplus_delete_cat+0x10/0x10[ 174.854507][ T9784] hfsplus_unlink+0x1ca/0x7c0[ 174.854516][ T9784] ? __pfx_hfsplus_unlink+0x10/0x10[ 174.854525][ T9784] ? down_write+0x148/0x200[ 174.854532][ T9784] ? __pfx_down_write+0x10/0x10[ 174.854540][ T9784] vfs_unlink+0x2fe/0x9b0[ 174.854549][ T9784] do_unlinkat+0x490/0x670[ 174.854557][ T9784] ? __pfx_do_unlinkat+0x10/0x10[ 174.854565][ T9784] ? __might_fault+0xbc/0x130[ 174.854576][ T9784] ? getname_flags.part.0+0x1c5/0x550[ 174.854584][ T9784] __x64_sys_unlink+0xc5/0x110[ 174.854592][ T9784] do_syscall_64+0xc9/0x480[ 174.854600][ T9784] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167[ 174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08[ 174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057[ 174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167[ 174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50[ 174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40[ 174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0[ 174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 174.854658][ T9784] [ 174.854661][ T9784][ 174.879281][ T9784] Allocated by task 9784:[ 174.879664][ T9784] kasan_save_stack+0x20/0x40[ 174.880082][ T9784] kasan_save_track+0x14/0x30[ 174.880500][ T9784] __kasan_kmalloc+0xaa/0xb0[ 174.880908][ T9784] __kmalloc_noprof+0x205/0x550[ 174.881337][ T9784] __hfs_bnode_create+0x107/0x890[ 174.881779][ T9784] hfsplus_bnode_find+0x2d0/0xd10[ 174.882222][ T9784] hfsplus_brec_find+0x2b0/0x520[ 174.882659][ T9784] hfsplus_delete_all_attrs+0x23b/0x3---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40043 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: nci: Add parameter validation for packet dataSyzbot reported an uninitialized value bug in nci_init_req, which wasintroduced by commit 5aca7966d2a7 ("Merge tag'perf-tools-fixes-for-v6.17-2025-09-16' ofgit://git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools").This bug arises due to very limited and poor input validationthat was done at nic_valid_size(). This validation onlyvalidates the skb->len (directly reflects size provided at theuserspace interface) with the length provided in the bufferitself (interpreted as NCI_HEADER). This leads to the processingof memory content at the address assuming the correct layoutper what opcode requires there. This leads to the accesses tobuffer of `skb_buff->data` which is not assigned anything yet.Following the same silent drop of packets of invalid sizes at`nic_valid_size()`, add validation of the data in the respectivehandlers and return error values in case of failure. Releasethe skb if error values are returned from handlers in`nci_nft_packet` and effectively do a silent dropPossible TODO: because we silently drop the packets, thecall to `nci_request` will be waiting for completion of requestand will face timeouts. These timeouts can get excessively loggedin the dmesg. A proper handling of them may require to export`nci_request_cancel` (or propagate error handling from thenft packets handlers).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40044 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: udf: fix OOB read in lengthAllocDescs handlingWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes fromon-disk data and must be validated against the block size. Crafted orcorrupted images may set lengthAllocDescs so that the total descriptorlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,leading udf_update_tag() to call crc_itu_t() on out-of-bounds memory andtrigger a KASAN use-after-free read.BUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60Read of size 1 at addr ffff888041e7d000 by task syz-executor317/5309CPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60 udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261 udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179 extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46 udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106 udf_release_file+0xc1/0x120 fs/udf/file.c:185 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Validate the computed total length against epos->bh->b_size.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40099 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: parse_dfs_referrals: prevent oob on malformed inputMalicious SMB server can send invalid reply to FSCTL_DFS_GET_REFERRALS- reply smaller than sizeof(struct get_dfs_referral_rsp)- reply with number of referrals smaller than NumberOfReferrals in theheaderProcessing of such replies will cause oob.Return -EINVAL error on such replies to prevent oob-s.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40149 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:tls: Use __sk_dst_get() and dst_dev_rcu() in get_netdev_for_sock().get_netdev_for_sock() is called during setsockopt(),so not under RCU.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the only ->ndo_sk_get_lower_dev() user isbond_sk_get_lower_dev(), which uses RCU.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40158 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_output()Use RCU in ip6_output() in order to use dst_dev_rcu() to preventpossible UAF.We can remove rcu_read_lock()/rcu_read_unlock() pairsfrom ip6_finish_output2().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40168 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Use __sk_dst_get() and dst_dev_rcu() in smc_clc_prfx_match().smc_clc_prfx_match() is called from smc_listen_work() andnot under RCU nor RTNL.Using sk_dst_get(sk)->dev could trigger UAF.Let's use __sk_dst_get() and dst_dev_rcu().Note that the returned value of smc_clc_prfx_match() is notused in the caller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40170 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: use dst_dev_rcu() in sk_setup_caps()Use RCU to protect accesses to dst->dev from sk_setup_caps()and sk_dst_gso_max_size().Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(),and ip_dst_mtu_maybe_forward().ip4_dst_hoplimit() can use dst_dev_net_rcu().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40180 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loopThe cleanup loop was starting at the wrong array index, causingout-of-bounds access.Start the loop at the correct index for zero-indexed arrays to preventaccessing memory beyond the allocated array bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40211 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: Fix use-after-free in acpi_video_switch_brightness()The switch_brightness_work delayed work accesses device->brightnessand device->backlight, freed by acpi_video_dev_unregister_backlight()during device removal.If the work executes after acpi_video_bus_unregister_backlight()frees these resources, it causes a use-after-free whenacpi_video_switch_brightness() dereferences device->brightness ordevice->backlight.Fix this by calling cancel_delayed_work_sync() for each device'sswitch_brightness_work in acpi_video_bus_remove_notify_handler()after removing the notify handler that queues the work. This ensuresthe work completes before the memory is freed.[ rjw: Changelog edit ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68188 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: use dst_dev_rcu() in tcp_fastopen_active_disable_ofo_check()Use RCU to avoid a pair of atomic operations and a potentialUAF on dst_dev()->flags.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68255 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix stack buffer overflow in OnAssocReq IE parsingThe Supported Rates IE length from an incoming Association Request framewas used directly as the memcpy() length when copying into a fixed-size16-byte stack buffer (supportRate). A malicious station can advertise anIE length larger than 16 bytes, causing a stack buffer overflow.Clamp ie_len to the buffer size before copying the Supported Rates IE,and correct the bounds check when merging Extended Supported Rates toprevent a second potential overflow.This prevents kernel stack corruption triggered by malformed associationrequests.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68264 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: refresh inline data size before write operationsThe cached ei->i_inline_size can become stale between the initial sizecheck and when ext4_update_inline_data()/ext4_create_inline_data() useit. Although ext4_get_max_inline_size() reads the correct value at thetime of the check, concurrent xattr operations can modify i_inline_sizebefore ext4_write_lock_xattr() is acquired.This causes ext4_update_inline_data() and ext4_create_inline_data() towork with stale capacity values, leading to a BUG_ON() crash inext4_write_inline_data(): kernel BUG at fs/ext4/inline.c:1331! BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);The race window:1. ext4_get_max_inline_size() reads i_inline_size = 60 (correct)2. Size check passes for 50-byte write3. [Another thread adds xattr, i_inline_size changes to 40]4. ext4_write_lock_xattr() acquires lock5. ext4_update_inline_data() uses stale i_inline_size = 606. Attempts to write 50 bytes but only 40 bytes actually available7. BUG_ON() triggersFix this by recalculating i_inline_size via ext4_find_inline_data_nolock()immediately after acquiring xattr_sem. This ensures ext4_update_inline_data()and ext4_create_inline_data() work with current values that are protectedfrom concurrent modifications.This is similar to commit a54c4613dac1 ("ext4: fix race writing to aninline_data file while its xattrs are changing") which fixed i_inline_offstaleness. This patch addresses the related i_inline_size staleness issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68324 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: imm: Fix use-after-free bug caused by unfinished delayed workThe delayed work item 'imm_tq' is initialized in imm_attach() andscheduled via imm_queuecommand() for processing SCSI commands. When theIMM parallel port SCSI host adapter is detached through imm_detach(),the imm_struct device instance is deallocated.However, the delayed work might still be pending or executingwhen imm_detach() is called, leading to use-after-free bugswhen the work function imm_interrupt() accesses the alreadyfreed imm_struct memory.The race condition can occur as follows:CPU 0(detach thread) | CPU 1 | imm_queuecommand() | imm_queuecommand_lck()imm_detach() | schedule_delayed_work() kfree(dev) //FREE | imm_interrupt() | dev = container_of(...) //USE dev-> //USEAdd disable_delayed_work_sync() in imm_detach() to guarantee propercancellation of the delayed work item before imm_struct is deallocated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68785 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix middle attribute validation in push_nsh() actionThe push_nsh() action structure looks like this: OVS_ACTION_ATTR_PUSH_NSH(OVS_KEY_ATTR_NSH(OVS_NSH_KEY_ATTR_BASE,...))The outermost OVS_ACTION_ATTR_PUSH_NSH attribute is OK'ed by thenla_for_each_nested() inside __ovs_nla_copy_actions(). The innermostOVS_NSH_KEY_ATTR_BASE/MD1/MD2 are OK'ed by the nla_for_each_nested()inside nsh_key_put_from_nlattr(). But nothing checks if the attributein the middle is OK. We don't even check that this attribute is theOVS_KEY_ATTR_NSH. We just do a double unwrap with a pair of nla_data()calls - first time directly while calling validate_push_nsh() and thesecond time as part of the nla_for_each_nested() macro, which isn'tsafe, potentially causing invalid memory access if the size of thisattribute is incorrect. The failure may not be noticed duringvalidation due to larger netlink buffer, but cause trouble later duringaction execution where the buffer is allocated exactly to the size: BUG: KASAN: slab-out-of-bounds in nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] Read of size 184 at addr ffff88816459a634 by task a.out/22624 CPU: 8 UID: 0 PID: 22624 6.18.0-rc7+ #115 PREEMPT(voluntary) Call Trace: dump_stack_lvl+0x51/0x70 print_address_description.constprop.0+0x2c/0x390 kasan_report+0xdd/0x110 kasan_check_range+0x35/0x1b0 __asan_memcpy+0x20/0x60 nsh_hdr_from_nlattr+0x1dd/0x6a0 [openvswitch] push_nsh+0x82/0x120 [openvswitch] do_execute_actions+0x1405/0x2840 [openvswitch] ovs_execute_actions+0xd5/0x3b0 [openvswitch] ovs_packet_cmd_execute+0x949/0xdb0 [openvswitch] genl_family_rcv_msg_doit+0x1d6/0x2b0 genl_family_rcv_msg+0x336/0x580 genl_rcv_msg+0x9f/0x130 netlink_rcv_skb+0x11f/0x370 genl_rcv+0x24/0x40 netlink_unicast+0x73e/0xaa0 netlink_sendmsg+0x744/0xbf0 __sys_sendto+0x3d6/0x450 do_syscall_64+0x79/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e Let's add some checks that the attribute is properly sized and it'sthe only one attribute inside the action. Technically, there is noreal reason for OVS_KEY_ATTR_NSH to be there, as we know that we'repushing an NSH header already, it just creates extra nesting, butthat's how uAPI works today. So, keeping as it is.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68794 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:iomap: adjust read range correctly for non-block-aligned positionsiomap_adjust_read_range() assumes that the position and length passed inare block-aligned. This is not always the case however, as shown in thesyzbot generated case for erofs. This causes too many bytes to beskipped for uptodate blocks, which results in returning the incorrectposition and length to read in. If all the blocks are uptodate, thisunderflows length and returns a position beyond the folio.Fix the calculation to also take into account the block offset whencalculating how many bytes can be skipped for uptodate blocks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71116 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: make decode_pool() more resilient against corrupted osdmapsIf the osdmap is (maliciously) corrupted such that the encoded lengthof ceph_pg_pool envelope is less than what is expected for a particularencoding version, out-of-bounds reads may ensue because the only boundscheck that is there is based on that length value.This patch adds explicit bounds checks for each field that is decodedor skipped.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-38469 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-38471 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-38472 Severity: Moderate CVSS3 score: 6.2

Description: A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2023-52491 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_runIn mtk_jpeg_probe, &jpeg->job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0 CPU1mtk_jpeg_dec_... | start worker | |mtk_jpeg_job_timeout_workmtk_jpeg_remove | v4l2_m2m_release | kfree(m2m_dev); | | | v4l2_m2m_get_curr_priv | m2m_dev->curr_ctx //useIf we close the file descriptor, which will call mtk_jpeg_release,it will have a similar sequence.Fix this bug by starting timeout worker only if started jpegdec workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53484 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:lib: cpu_rmap: Avoid use after free on rmap->obj array entriesWhen calling irq_set_affinity_notifier() with NULL at the notifyargument, it will cause freeing of the glue pointer in thecorresponding array entry but will leave the pointer in the array. Asubsequent call to free_irq_cpu_rmap() will try to free this entry againleading to possible use after free.Fix that by setting NULL to the array entry and checking that we havenon-zero at the array entry when iterating over the array infree_irq_cpu_rmap().The current code does not suffer from this since there are no caseswhere irq_set_affinity_notifier(irq, NULL) (note the NULL passed for thenotify arg) is called, followed by a call to free_irq_cpu_rmap() so wedon't hit and issue. Subsequent patches in this series excersize thisflow, hence the required fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54169 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_ptp_openWhen kvzalloc_node or kvzalloc failed in mlx5e_ptp_open, the memorypointed by "c" or "cparams" is not freed, which can lead to a memoryleak. Fix by freeing the array in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54265 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix an uninit variable access bug in __ip6_make_skb()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline]BUG: KMSAN: uninit-value in arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline]BUG: KMSAN: uninit-value in atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline]BUG: KMSAN: uninit-value in __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 arch_atomic64_inc arch/x86/include/asm/atomic64_64.h:88 [inline] arch_atomic_long_inc include/linux/atomic/atomic-long.h:161 [inline] atomic_long_inc include/linux/atomic/atomic-instrumented.h:1429 [inline] __ip6_make_skb+0x2f37/0x30f0 net/ipv6/ip6_output.c:1956 ip6_finish_skb include/net/ipv6.h:1122 [inline] ip6_push_pending_frames+0x10e/0x550 net/ipv6/ip6_output.c:1987 rawv6_push_pending_frames+0xb12/0xb90 net/ipv6/raw.c:579 rawv6_sendmsg+0x297e/0x2e60 net/ipv6/raw.c:922 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 alloc_skb include/linux/skbuff.h:1270 [inline] __ip6_append_data+0x51c1/0x6bb0 net/ipv6/ip6_output.c:1684 ip6_append_data+0x411/0x580 net/ipv6/ip6_output.c:1854 rawv6_sendmsg+0x2882/0x2e60 net/ipv6/raw.c:915 inet_sendmsg+0x101/0x180 net/ipv4/af_inet.c:827 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xa8e/0xe70 net/socket.c:2476 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2530 __sys_sendmsg net/socket.c:2559 [inline] __do_sys_sendmsg net/socket.c:2568 [inline] __se_sys_sendmsg net/socket.c:2566 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2566 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because icmp6hdr does not in skb linear region under the scenarioof SOCK_RAW socket. Access icmp6_hdr(skb)->icmp6_type directly willtrigger the uninit variable access bug.Use a local variable icmp6_type to carry the correct value in differentscenarios.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-6915 Severity: Moderate CVSS3 score: 6.2

Description: A Null pointer dereference problem was found in ida_free in lib/idr.c in the Linux Kernel. This issue may allow an attacker using this library to cause a denial of service problem due to a missing check at a function return.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38428 Severity: Moderate CVSS3 score: 6.2

Description: url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-45490 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-45491 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-45492 Severity: Moderate CVSS3 score: 6.2

Description: An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2025-37849 Severity: Moderate CVSS3 score: 6.2

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Tear down vGIC on failed vCPU creationIf kvm_arch_vcpu_create() fails to share the vCPU page with thehypervisor, we propagate the error back to the ioctl but leave thevGIC vCPU data initialised. Note only does this leak the correspondingmemory when the vCPU is destroyed but it can also lead to use-after-freeif the redistributor device handling tries to walk into the vCPU.Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that thevGIC vCPU structures are destroyed on error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40909 Severity: Moderate CVSS3 score: 6.2

Description: Perl threads have a working directory race condition where file operations may target unintended paths.If a directory handle is open at thread creation, the process-wide current working directory is temporarily changed in order to clone that handle for the new thread, which is visible from any third (or more) thread already running. This may lead to unintended operations such as loading code or accessing files from unexpected locations, which a local attacker may be able to exploit.The bug was introduced in commit 11a11ecf4bea72b17d250cfb43c897be1341861e and released in Perl version 5.13.6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
perl > 0-0 (version in image is 5.26.1-150300.17.20.1).

CVE-2025-62349 Severity: Moderate CVSS3 score: 6.2

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-salt < 3006.0-150400.8.91.1 (version in image is 3006.0-150400.8.83.6).

CVE-2025-9714 Severity: Moderate CVSS3 score: 6.2

Description: Uncontrolled recursion in XPath evaluation in libxml2 up to and including version 2.9.14 allows a local attacker to cause a stack overflow via crafted expressions. XPath processing functions `xmlXPathRunEval`, `xmlXPathCtxtCompile`, and `xmlXPathEvalExpr` were resetting recursion depth to zero before making potentially recursive calls. When such functions were called recursively this could allow for uncontrolled recursion and lead to a stack overflow. These functions now preserve recursion depth across recursive calls, allowing recursion depth to be controlled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 < 2.9.14-150400.5.50.1 (version in image is 2.9.14-150400.5.47.1).

CVE-2022-48980 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: avoid out of bounds access in sja1105_init_l2_policing()The SJA1105 family has 45 L2 policing table entries(SJA1105_MAX_L2_POLICING_COUNT) and SJA1110 has 110(SJA1110_MAX_L2_POLICING_COUNT). Keeping the table structure butaccounting for the difference in port count (5 in SJA1105 vs 10 inSJA1110) does not fully explain the difference. Rather, the SJA1110 alsohas L2 ingress policers for multicast traffic. If a packet is classifiedas multicast, it will be processed by the policer index 99 + SRCPORT.The sja1105_init_l2_policing() function initializes all L2 policers suchthat they don't interfere with normal packet reception by default. To havea common code between SJA1105 and SJA1110, the index of the multicastpolicer for the port is calculated because it's an index that is out ofbounds for SJA1105 but in bounds for SJA1110, and a bounds check isperformed.The code fails to do the proper thing when determining what to do with themulticast policer of port 0 on SJA1105 (ds->num_ports = 5). The "mcast"index will be equal to 45, which is also equal totable->ops->max_entry_count (SJA1105_MAX_L2_POLICING_COUNT). So it passesthrough the check. But at the same time, SJA1105 doesn't have multicastpolicers. So the code programs the SHARINDX field of an out-of-boundselement in the L2 Policing table of the static config.The comparison between index 45 and 45 entries should have determined thecode to not access this policer index on SJA1105, since its memory wasn'teven allocated.With enough bad luck, the out-of-bounds write could even overwrite othervalid kernel data, but in this case, the issue was detected using KASAN.Kernel log:sja1105 spi5.0: Probed switch chip: SJA1105Q==================================================================BUG: KASAN: slab-out-of-bounds in sja1105_setup+0x1cbc/0x2340Write of size 8 at addr ffffff880bd57708 by task kworker/u8:0/8...Workqueue: events_unbound deferred_probe_work_funcCall trace:...sja1105_setup+0x1cbc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...Allocated by task 8:...sja1105_setup+0x1bcc/0x2340dsa_register_switch+0x1284/0x18d0sja1105_probe+0x748/0x840...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50400 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:staging: greybus: audio_helper: remove unused and wrong debugfs usageIn the greybus audio_helper code, the debugfs file for the dapm has thepotential to be removed and memory will be leaked. There is also thevery real potential for this code to remove ALL debugfs entries from thesystem, and it seems like this is what will really happen if this codeever runs. This all is very wrong as the greybus audio driver did notcreate this debugfs file, the sound core did and controls the lifespanof it.So remove all of the debugfs logic from the audio_helper code as there'sno way it could be correct. If this really is needed, it can come backwith a fixup for the incorrect usage of the debugfs_lookup() call whichis what caused this to be noticed at all.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50567 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:fs: jfs: fix shift-out-of-bounds in dbAllocAGSyzbot found a crash : UBSAN: shift-out-of-bounds in dbAllocAG. Theunderlying bug is the missing check of bmp->db_agl2size. The field canbe greater than 64 and trigger the shift-out-of-bounds.Fix this bug by adding a check of bmp->db_agl2size in dbMount since thisfield is used in many following functions. The upper bound for thisfield is L2MAXL2SIZE - L2MAXAG, thanks for the help of Dave Kleikamp.Note that, for maintenance, I reorganized error handling code of dbMount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50580 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:blk-throttle: prevent overflow while calculating wait timeThere is a problem found by code review in tg_with_in_bps_limit() that'bps_limit * jiffy_elapsed_rnd' might overflow. Fix the problem bycalling mul_u64_u64_div_u64() instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53220 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: az6007: Fix null-ptr-deref in az6007_i2c_xfer()In az6007_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach az6007_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53456 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Add length check when parsing nlattrsThere are three places that qla4xxx parses nlattrs: - qla4xxx_set_chap_entry() - qla4xxx_iface_set_param() - qla4xxx_sysfs_ddb_set_param()and each of them directly converts the nlattr to specific pointer ofstructure without length checking. This could be dangerous as thoseattributes are not validated and a malformed nlattr (e.g., length 0) couldresult in an OOB read that leaks heap dirty data.Add the nla_len check before accessing the nlattr data and return EINVAL ifthe length check fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53541 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: Fix potential out-of-bounds access in oob writeWhen the oob buffer length is not in multiple of words, the oob writefunction does out-of-bounds read on the oob source buffer at the lastiteration. Fix that by always checking length limit on the oob bufferread and fill with 0xff when reaching the end of the buffer to the oobregisters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53582 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-boundsFix a stack-out-of-bounds read in brcmfmac that occurswhen 'buf' that is not null-terminated is passed as an argument ofstrreplace() in brcmf_c_preinit_dcmds(). This buffer is filled witha CLM version string by memcpy() in brcmf_fil_iovar_data_get().Ensure buf is null-terminated.Found by a modified version of syzkaller.[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22[ 33.021554][ T1896] ==================================================================[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896[ 33.023852][ T1896][ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event[ 33.026581][ T1896] Call Trace:[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334[ 33.028037][ T1896] ? strreplace+0xf2/0x110[ 33.028403][ T1896] ? strreplace+0xf2/0x110[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf[ 33.029283][ T1896] ? strreplace+0xf2/0x110[ 33.029666][ T1896] strreplace+0xf2/0x110[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0[ 33.033582][ T1896] brcmf_attach+0x246/0xd40[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50[ 33.034383][ T1896] ? kmemdup+0x30/0x40[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710[ 33.036315][ T1896] really_probe+0x1be/0xa90[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0[ 33.037383][ T1896] driver_probe_device+0x49/0x120[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120[ 33.042330][ T1896] __device_attach+0x207/0x330[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260[ 33.043914][ T1896] device_add+0xa61/0x1ce0[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90[ 33.046931][ T1896] usb_probe_device+0x9c/0x220[ 33.047434][ T1896] really_probe+0x1be/0xa90[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460[ 33.048134][ T1896] driver_probe_device+0x49/0x120[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53624 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_fq: fix integer overflow of "credit"if sch_fq is configured with "initial quantum" having values greater thanINT_MAX, the first assignment of "credit" does signed integer overflow toa very negative value.In this situation, the syzkaller script provided by Cristoph triggers theCPU soft-lockup warning even with few sockets. It's not an infinite loop,but "credit" wasn't probably meant to be minus 2Gb for each new flow.Capping "initial quantum" to INT_MAX proved to fix the issue.v2: validation of "initial quantum" is done in fq_policy, instead of open coding in fq_change() _ suggested by Jakub Kicinski

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53635 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: fix wrong ct->timeout value(struct nf_conn)->timeout is an interval before the conntrackconfirmed. After confirmed, it becomes a timestamp.It is observed that timeout of an unconfirmed conntrack:- Set by calling ctnetlink_change_timeout(). As a result, `nfct_time_stamp` was wrongly added to `ct->timeout` twice.- Get by calling ctnetlink_dump_timeout(). As a result, `nfct_time_stamp` was wrongly subtracted.Call Trace: dump_stack_lvl ctnetlink_dump_timeout __ctnetlink_glue_build ctnetlink_glue_build __nfqnl_enqueue_packet nf_queue nf_hook_slow ip_mc_output ? __pfx_ip_finish_output ip_send_skb ? __pfx_dst_output udp_send_skb udp_sendmsg ? __pfx_ip_generic_getfrag sock_sendmsgSeparate the 2 cases in:- Setting `ct->timeout` in __nf_ct_set_timeout().- Getting `ct->timeout` in ctnetlink_dump_timeout().Pablo appends:Update ctnetlink to set up the timeout _after_ the IPS_CONFIRMED flag isset on, otherwise conntrack creation via ctnetlink breaks.Note that the problem described in this patch occurs since theintroduction of the nfnetlink_queue conntrack support, select asufficiently old Fixes: tag for -stable kernel to pick up this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53667 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: cdc_ncm: Deal with too low values of dwNtbOutMaxSizeCurrently in cdc_ncm_check_tx_max(), if dwNtbOutMaxSize is lower thanthe calculated "min" value, but greater than zero, the logic setstx_max to dwNtbOutMaxSize. This is then used to allocate a new SKB incdc_ncm_fill_tx_frame() where all the data is handled.For small values of dwNtbOutMaxSize the memory allocated duringalloc_skb(dwNtbOutMaxSize, GFP_ATOMIC) will have the same size, due tohow size is aligned at alloc time: size = SKB_DATA_ALIGN(size); size += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));Thus we hit the same bug that we tried to squash withcommit 2be6d4d16a084 ("net: cdc_ncm: Allow for dwNtbOutMaxSize to be unset or zero")Low values of dwNtbOutMaxSize do not cause an issue presently because atalloc_skb() time more memory (512b) is allocated than required for theSKB headers alone (320b), leaving some space (512b - 320b = 192b)for CDC data (172b).However, if more elements (for example 3 x u64 = [24b]) were added toone of the SKB header structs, say 'struct skb_shared_info',increasing its original size (320b [320b aligned]) to something larger(344b [384b aligned]), then suddenly the CDC data (172b) no longerfits in the spare SKB data area (512b - 384b = 128b).Consequently the SKB bounds checking semantics fails and panics:skbuff: skb_over_panic: text:ffffffff831f755b len:184 put:172 head:ffff88811f1c6c00 data:ffff88811f1c6c00 tail:0xb8 end:0x80 dev:------------[ cut here ]------------kernel BUG at net/core/skbuff.c:113!invalid opcode: 0000 [#1] PREEMPT SMP KASANCPU: 0 PID: 57 Comm: kworker/0:2 Not tainted 5.15.106-syzkaller-00249-g19c0ed55a470 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023Workqueue: mld mld_ifc_workRIP: 0010:skb_panic net/core/skbuff.c:113 [inline]RIP: 0010:skb_over_panic+0x14c/0x150 net/core/skbuff.c:118[snip]Call Trace: skb_put+0x151/0x210 net/core/skbuff.c:2047 skb_put_zero include/linux/skbuff.h:2422 [inline] cdc_ncm_ndp16 drivers/net/usb/cdc_ncm.c:1131 [inline] cdc_ncm_fill_tx_frame+0x11ab/0x3da0 drivers/net/usb/cdc_ncm.c:1308 cdc_ncm_tx_fixup+0xa3/0x100Deal with too low values of dwNtbOutMaxSize, clamp it in the range[USB_CDC_NCM_NTB_MIN_OUT_SIZE, CDC_NCM_NTB_MAX_SIZE_TX]. We ensureenough data space is allocated to handle CDC data by making suredwNtbOutMaxSize is not smaller than USB_CDC_NCM_NTB_MIN_OUT_SIZE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54182 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to check readonly condition correctlyWith below case, it can mount multi-device image w/ rw option, howeverone of secondary device is set as ro, later update will cause panic, solet's introduce f2fs_dev_is_readonly(), and check multi-devices rw statusin f2fs_remount() w/ it in order to avoid such inconsistent mount status.mkfs.f2fs -c /dev/zram1 /dev/zram0 -fblockdev --setro /dev/zram1mount -t f2fs dev/zram0 /mnt/f2fsmount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.mount -t f2fs -o remount,rw mnt/f2fsdd if=/dev/zero of=/mnt/f2fs/file bs=1M count=8192kernel BUG at fs/f2fs/inline.c:258!RIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]Call Trace: f2fs_write_single_data_page+0x26b/0x9f0 [f2fs] f2fs_write_cache_pages+0x389/0xa60 [f2fs] __f2fs_write_data_pages+0x26b/0x2d0 [f2fs] f2fs_write_data_pages+0x2e/0x40 [f2fs] do_writepages+0xd3/0x1b0 __writeback_single_inode+0x5b/0x420 writeback_sb_inodes+0x236/0x5a0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x2a3/0x490 wb_do_writeback+0x2b2/0x330 wb_workfn+0x6a/0x260 process_one_work+0x270/0x5e0 worker_thread+0x52/0x3e0 kthread+0xf4/0x120 ret_from_fork+0x29/0x50

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54232 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:m68k: Only force 030 bus error if PC not in exception table__get_kernel_nofault() does copy data in supervisor mode whenforcing a task backtrace log through /proc/sysrq_trigger.This is expected cause a bus error exception on e.g. NULLpointer dereferencing when logging a kernel task has noworkqueue associated. This bus error ought to be ignored.Our 030 bus error handler is ill equipped to deal with this:Whenever ssw indicates a kernel mode access on a data fault,we don't even attempt to handle the fault and instead alwayssend a SEGV signal (or panic). As a result, the checkfor exception handling at the fault PC (buried insend_sig_fault() which gets called from do_page_fault()eventually) is never used.In contrast, both 040 and 060 access error handlers do notcare whether a fault happened on supervisor mode access,and will call do_page_fault() on those, ultimately honoringthe exception table.Add a check in bus_error030 to call do_page_fault() in casewe do have an entry for the fault PC in our exception table.I had attempted a fix for this earlier in 2019 that did relyon testing pagefault_disabled() (see link below) to achievethe same thing, but this patch should be more generic.Tested on 030 Atari Falcon.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54243 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix table blob use-after-freeWe are not allowed to return an error at this point.Looking at the code it looks like ret is always 0 at thispoint, but its not.t = find_table_lock(net, repl->name, &ret, &ebt_mutex);... this can return a valid table, with ret != 0.This bug causes update of table->private with the newblob, but then frees the blob right away in the caller.Syzbot report:BUG: KASAN: vmalloc-out-of-bounds in __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168Read of size 4 at addr ffffc90005425000 by task kworker/u4:4/74Workqueue: netns cleanup_netCall Trace: kasan_report+0xbf/0x1f0 mm/kasan/report.c:517 __ebt_unregister_table+0xc00/0xcd0 net/bridge/netfilter/ebtables.c:1168 ebt_unregister_table+0x35/0x40 net/bridge/netfilter/ebtables.c:1372 ops_exit_list+0xb0/0x170 net/core/net_namespace.c:169 cleanup_net+0x4ee/0xb10 net/core/net_namespace.c:613...ip(6)tables appears to be ok (ret should be 0 at this point) but makethis more obvious.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54312 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:samples/bpf: Fix buffer overflow in tcp_baserttUsing sizeof(nv) or strlen(nv)+1 is correct.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54316 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:refscale: Fix uninitalized use of wait_queue_head_tRunning the refscale test occasionally crashes the kernel with thefollowing error:[ 8569.952896] BUG: unable to handle page fault for address: ffffffffffffffe8[ 8569.952900] #PF: supervisor read access in kernel mode[ 8569.952902] #PF: error_code(0x0000) - not-present page[ 8569.952904] PGD c4b048067 P4D c4b049067 PUD c4b04b067 PMD 0[ 8569.952910] Oops: 0000 [#1] PREEMPT_RT SMP NOPTI[ 8569.952916] Hardware name: Dell Inc. PowerEdge R750/0WMWCR, BIOS 1.2.4 05/28/2021[ 8569.952917] RIP: 0010:prepare_to_wait_event+0x101/0x190 :[ 8569.952940] Call Trace:[ 8569.952941] [ 8569.952944] ref_scale_reader+0x380/0x4a0 [refscale][ 8569.952959] kthread+0x10e/0x130[ 8569.952966] ret_from_fork+0x1f/0x30[ 8569.952973] The likely cause is that init_waitqueue_head() is called after the call tothe torture_create_kthread() function that creates the ref_scale_readerkthread. Although this init_waitqueue_head() call will very likelycomplete before this kthread is created and starts running, it ispossible that the calling kthread will be delayed between the calls totorture_create_kthread() and init_waitqueue_head(). In this case, thenew kthread will use the waitqueue head before it is properly initialized,which is not good for the kernel's health and well-being.The above crash happened here: static inline void __add_wait_queue(...) { : if (!(wq->flags & WQ_FLAG_PRIORITY)) <=== Crash hereThe offset of flags from list_head entry in wait_queue_entry is-0x18. If reader_tasks[i].wq.head.next is NULL as allocated reader_taskstructure is zero initialized, the instruction will try to access address0xffffffffffffffe8, which is exactly the fault address listed above.This commit therefore invokes init_waitqueue_head() before creatingthe kthread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-6606 Severity: Moderate CVSS3 score: 6.1

Description: An out-of-bounds read vulnerability was found in smbCalcSize in fs/smb/client/netmisc.c in the Linux Kernel. This issue could allow a local attacker to crash the system or leak internal kernel information.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0607 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in the Netfilter subsystem in the Linux kernel. The issue is in the nft_byteorder_eval() function, where the code iterates through a loop and writes to the `dst` array. On each iteration, 8 bytes are written, but `dst` is an array of u32, so each element only has space for 4 bytes. That means every iteration overwrites part of the previous element corrupting this array of u32. This flaw allows a local user to cause a denial of service or potentially break NetFilter functionality.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-10524 Severity: Moderate CVSS3 score: 6.1

Description: Applications that use Wget to access a remote resource using shorthand URLs and pass arbitrary user credentials in the URL are vulnerable. In these cases attackers can enter crafted credentials which will cause Wget to access an arbitrary host.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
wget > 0-0 (version in image is 1.20.3-150000.3.29.1).

CVE-2024-26635 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:llc: Drop support for ETH_P_TR_802_2.syzbot reported an uninit-value bug below. [0]llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2(0x0011), and syzbot abused the latter to trigger the bug. write$tun(r0, &(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', "90e5dd"}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb->protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e("net: delete all instances of special processing for token ring").It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let's remove llc_tr_packet_type and complete the deprecation.[0]:BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90 __llc_lookup_established+0xe9d/0xf90 __llc_lookup net/llc/llc_conn.c:611 [inline] llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206 __netif_receive_skb_one_core net/core/dev.c:5527 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641 netif_receive_skb_internal net/core/dev.c:5727 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5786 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x1490 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26641 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].Call pskb_inet_may_pull() to fix this, and initialize ipv6hvariable after this call as it can change skb->head.[1] BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321 ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727 __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845 ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888 gre_rcv+0x143f/0x1870 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:461 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5532 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646 netif_receive_skb_internal net/core/dev.c:5732 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5791 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2084 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x786/0x1200 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27306 Severity: Moderate CVSS3 score: 6.1

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. A XSS vulnerability exists on index pages for static file handling. This vulnerability is fixed in 3.9.4. We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected. Other users can disable `show_index` if unable to upgrade.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2024-34064 Severity: Moderate CVSS3 score: 6.1

Description: Jinja is an extensible templating engine. The `xmlattr` filter in affected versions of Jinja accepts keys containing non-attribute characters. XML/HTML attributes cannot contain spaces, `/`, `>`, or `=`, as each would then be interpreted as starting a separate attribute. If an application accepts keys (as opposed to only values) as user input, and renders these in pages that other users see as well, an attacker could use this to inject other attributes and perform XSS. The fix for CVE-2024-22195 only addressed spaces but not other characters. Accepting keys as user input is now explicitly considered an unintended use case of the `xmlattr` filter, and code that does so without otherwise validating the input should be flagged as insecure, regardless of Jinja version. Accepting _values_ as user input continues to be safe. This vulnerability is fixed in 3.1.4.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).

CVE-2024-36025 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix off by one in qla_edif_app_getstats()The app_reply->elem[] array is allocated earlier in this function and ithas app_req.num_ports elements. Thus this > comparison needs to be >= toprevent memory corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36960 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat's actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37354 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix crash on racing fsync and size-extending write into preallocWe have been seeing crashes on duplicate keys inbtrfs_set_item_key_safe(): BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192) ------------[ cut here ]------------ kernel BUG at fs/btrfs/ctree.c:2620! invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]With the following stack trace: #0 btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4) #1 btrfs_drop_extents (fs/btrfs/file.c:411:4) #2 log_one_extent (fs/btrfs/tree-log.c:4732:9) #3 btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9) #4 btrfs_log_inode (fs/btrfs/tree-log.c:6626:9) #5 btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8) #6 btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8) #7 btrfs_sync_file (fs/btrfs/file.c:1933:8) #8 vfs_fsync_range (fs/sync.c:188:9) #9 vfs_fsync (fs/sync.c:202:9) #10 do_fsync (fs/sync.c:212:9) #11 __do_sys_fdatasync (fs/sync.c:225:9) #12 __se_sys_fdatasync (fs/sync.c:223:1) #13 __x64_sys_fdatasync (fs/sync.c:223:1) #14 do_syscall_x64 (arch/x86/entry/common.c:52:14) #15 do_syscall_64 (arch/x86/entry/common.c:83:7) #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)So we're logging a changed extent from fsync, which is splitting anextent in the log tree. But this split part already exists in the tree,triggering the BUG().This is the state of the log tree at the time of the crash, dumped withdrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)to get more details than btrfs_print_leaf() gives us: >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0]["eb"]) leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610 leaf 33439744 flags 0x100000000000000 fs uuid e5bd3946-400c-4223-8923-190ef1f18677 chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160 generation 7 transid 9 size 8192 nbytes 8473563889606862198 block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0 sequence 204 flags 0x10(PREALLOC) atime 1716417703.220000000 (2024-05-22 15:41:43) ctime 1716417704.983333333 (2024-05-22 15:41:44) mtime 1716417704.983333333 (2024-05-22 15:41:44) otime 17592186044416.000000000 (559444-03-08 01:40:16) item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13 index 195 namelen 3 name: 193 item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37 location key (0 UNKNOWN.0 0) type XATTR transid 7 data_len 1 name_len 6 name: user.a data a item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53 generation 9 type 1 (regular) extent data disk byte 303144960 nr 12288 extent data offset 0 nr 4096 ram 12288 extent compression 0 (none) item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 4096 nr 8192 item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53 generation 9 type 2 (prealloc) prealloc data disk byte 303144960 nr 12288 prealloc data offset 8192 nr 4096 ...So the real problem happened earlier: notice that items 4 (4k-12k) and 5(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size anditem 5 starts at i_size.Here is the state of ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38552 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential index out of bounds in color transformation functionFixes index out of bounds issue in the color transformation function.The issue could occur when the index 'i' exceeds the number of transferfunction points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, an error message islogged and the function returns false to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38594 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: move the EST lock to struct stmmac_privReinitialize the whole EST structure would also reset the mutexlock which is embedded in the EST structure, and then triggerthe following warning. To address this, move the lock to structstmmac_priv. We also need to reacquire the mutex lock when doingthis initialization.DEBUG_LOCKS_WARN_ON(lock->magic != lock)WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: __mutex_lock+0xd84/0x1068 mutex_lock_nested+0x28/0x34 tc_setup_taprio+0x118/0x68c stmmac_setup_tc+0x50/0xf0 taprio_change+0x868/0xc9c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39487 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()In function bond_option_arp_ip_targets_set(), if newval->string is anempty string, newval->string+1 will point to the byte after thestring, causing an out-of-bound read.BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0xc1/0x5e0 mm/kasan/report.c:475 kasan_report+0xbe/0xf0 mm/kasan/report.c:588 strlen+0x7d/0xa0 lib/string.c:418 __fortify_strlen include/linux/fortify-string.h:210 [inline] in4_pton+0xa3/0x3f0 net/core/utils.c:130 bond_option_arp_ip_targets_set+0xc2/0x910drivers/net/bonding/bond_options.c:1201 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156 dev_attr_store+0x54/0x80 drivers/base/core.c:2366 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334 call_write_iter include/linux/fs.h:2020 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x96a/0xd80 fs/read_write.c:584 ksys_write+0x122/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b---[ end trace ]---Fix it by adding a check of string length before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39505 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/komeda: check for error-valued pointerkomeda_pipeline_get_state() may return an error-valued pointer, thuscheck the pointer for negative or null value before dereferencing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86: stop playing stack games in profile_pc()The 'profile_pc()' function is used for timer-based profiling, whichisn't really all that relevant any more to begin with, but it also endsup making assumptions based on the stack layout that aren't necessarilyvalid.Basically, the code tries to account the time spent in spinlocks to thecaller rather than the spinlock, and while I support that as a concept,it's not worth the code complexity or the KASAN warnings when no seriousprofiling is done using timers anyway these days.And the code really does depend on stack layout that is only true in thesimplest of cases. We've lost the comment at some point (I think whenthe 32-bit and 64-bit code was unified), but it used to say: Assume the lock function has either no stack frame or a copy of eflags from PUSHF.which explains why it just blindly loads a word or two straight off thestack pointer and then takes a minimal look at the values to just checkif they might be eflags or the return pc: Eflags always has bits 22 and up cleared unlike kernel addressesbut that basic stack layout assumption assumes that there isn't any lockdebugging etc going on that would complicate the code and cause a stackframe.It causes KASAN unhappiness reported for years by syzkaller [1] andothers [2].With no real practical reason for this any more, just remove the code.Just for historical interest, here's some background commits relating tothis code from 2006: 0cb91a229364 ("i386: Account spinlocks to the caller during profiling for !FP kernels") 31679f38d886 ("Simplify profile_pc on x86-64")and a code unification from 2009: ef4512882dbe ("x86: time_32/64.c unify profile_pc")but the basics of this thing actually goes back to before the git tree.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: add missing check for inode numbers on directory entriesSyzbot reported that mounting and unmounting a specific pattern ofcorrupted nilfs2 filesystem images causes a use-after-free of metadatafile inodes, which triggers a kernel bug in lru_add_fn().As Jan Kara pointed out, this is because the link count of a metadata filegets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),tries to delete that inode (ifile inode in this case).The inconsistency occurs because directories containing the inode numbersof these metadata files that should not be visible in the namespace areread without checking.Fix this issue by treating the inode numbers of these internal files aserrors in the sanity check helper when reading directory folios/pages.Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layeranalysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42105 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix inode number range checksPatch series "nilfs2: fix potential issues related to reserved inodes".This series fixes one use-after-free issue reported by syzbot, caused bynilfs2's internal inode being exposed in the namespace on a corruptedfilesystem, and a couple of flaws that cause problems if the startingnumber of non-reserved inodes written in the on-disk super block isintentionally (or corruptly) changed from its default value. This patch (of 3):In the current implementation of nilfs2, "nilfs->ns_first_ino", whichgives the first non-reserved inode number, is read from the superblock,but its lower limit is not checked.As a result, if a number that overlaps with the inode number range ofreserved inodes such as the root directory or metadata files is set in thesuper block parameter, the inode number test macros (NILFS_MDT_INODE andNILFS_VALID_INODE) will not function properly.In addition, these test macros use left bit-shift calculations using withthe inode number as the shift count via the BIT macro, but the result of ashift calculation that exceeds the bit width of an integer is undefined inthe C specification, so if "ns_first_ino" is set to a large value otherthan the default value NILFS_USER_INO (=11), the macros may potentiallymalfunction depending on the environment.Fix these issues by checking the lower bound of "nilfs->ns_first_ino" andby preventing bit shifts equal to or greater than the NILFS_USER_INOconstant in the inode number test macros.Also, change the type of "ns_first_ino" from signed integer to unsignedinteger to avoid the need for type casting in comparisons such as thelower bound check introduced this time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42259 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Fix Virtual Memory mapping boundaries calculationCalculating the size of the mapped area as the lesser valuebetween the requested size and the actual size does not considerthe partial mapping offset. This can cause page fault access.Fix the calculation of the starting and ending addresses, thetotal size is now deduced from the difference between the end andstart addresses.Additionally, the calculations have been rewritten in a clearerand more understandable form.[Joonas: Add Requires: tag]Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset")(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53052 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/rw: fix missing NOWAIT check for O_DIRECT start writeWhen io_uring starts a write, it'll call kiocb_start_write() to bump thesuper block rwsem, preventing any freezes from happening while thatwrite is in-flight. The freeze side will grab that rwsem for writing,excluding any new writers from happening and waiting for existing writesto finish. But io_uring unconditionally uses kiocb_start_write(), whichwill block if someone is currently attempting to freeze the mount point.This causes a deadlock where freeze is waiting for previous writes tocomplete, but the previous writes cannot complete, as the task that issupposed to complete them is blocked waiting on starting a new write.This results in the following stuck trace showing that dependency withthe write blocked starting a new write:task:fio state:D stack:0 pid:886 tgid:886 ppid:876Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963with the attempting freezer stuck trying to grab the rwsem:task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt ablocking grab of the super block rwsem if it isn't set. For normal issuewhere IOCB_NOWAIT would always be set, this returns -EAGAIN which willhave io_uring core issue a blocking attempt of the write. That will inturn also get completions run, ensuring forward progress.Since freezing requires CAP_SYS_ADMIN in the first place, this isn'tsomething that can be triggered by a regular user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53099 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check validity of link->type in bpf_link_show_fdinfo()If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessingbpf_link_type_strs[link->type] may result in an out-of-bounds access.To spot such missed invocations early in the future, checking thevalidity of link->type in bpf_link_show_fdinfo() and emitting a warningwhen such invocations are missed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53138 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: kTLS, Fix incorrect page refcountingThe kTLS tx handling code is using a mix of get_page() andpage_ref_inc() APIs to increment the page reference. But on the releasepath (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used.This is an issue when using pages from large folios: the get_page()references are stored on the folio page while the page_ref_inc()references are stored directly in the given page. On release the foliopage will be dereferenced too many times.This was found while doing kTLS testing with sendfile() + ZC when theserved file was read from NFS on a kernel with NFS large folios support(commit 49b29a573da8 ("nfs: add support for large folios")).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53151 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: Address an integer overflowDan Carpenter reports:> Commit 78147ca8b4a9 ("svcrdma: Add a "parsed chunk list" data> structure") from Jun 22, 2020 (linux-next), leads to the following> Smatch static checker warning:>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c:498 xdr_check_write_chunk()> warn: potential user controlled sizeof overflow 'segcount * 4 * 4'>> net/sunrpc/xprtrdma/svc_rdma_recvfrom.c> 488 static bool xdr_check_write_chunk(struct svc_rdma_recv_ctxt *rctxt)> 489 {> 490 u32 segcount;> 491 __be32 *p;> 492> 493 if (xdr_stream_decode_u32(&rctxt->rc_stream, &segcount))> ^^^^^^^^>> 494 return false;> 495> 496 /* A bogus segcount causes this buffer overflow check to fail. */> 497 p = xdr_inline_decode(&rctxt->rc_stream,> --> 498 segcount * rpcrdma_segment_maxsz * sizeof(*p));>>> segcount is an untrusted u32. On 32bit systems anything >= SIZE_MAX / 16 will> have an integer overflow and some those values will be accepted by> xdr_inline_decode().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53155 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix uninitialized value in ocfs2_file_read_iter()Syzbot has reported the following KMSAN splat:BUG: KMSAN: uninit-value in ocfs2_file_read_iter+0x9a4/0xf80 ocfs2_file_read_iter+0x9a4/0xf80 __io_read+0x8d4/0x20f0 io_read+0x3e/0xf0 io_issue_sqe+0x42b/0x22c0 io_wq_submit_work+0xaf9/0xdc0 io_worker_handle_work+0xd13/0x2110 io_wq_worker+0x447/0x1410 ret_from_fork+0x6f/0x90 ret_from_fork_asm+0x1a/0x30Uninit was created at: __alloc_pages_noprof+0x9a7/0xe00 alloc_pages_mpol_noprof+0x299/0x990 alloc_pages_noprof+0x1bf/0x1e0 allocate_slab+0x33a/0x1250 ___slab_alloc+0x12ef/0x35e0 kmem_cache_alloc_bulk_noprof+0x486/0x1330 __io_alloc_req_refill+0x84/0x560 io_submit_sqes+0x172f/0x2f30 __se_sys_io_uring_enter+0x406/0x41c0 __x64_sys_io_uring_enter+0x11f/0x1a0 x64_sys_call+0x2b54/0x3ba0 do_syscall_64+0xcd/0x1e0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSince an instance of 'struct kiocb' may be passed from the block layerwith 'private' field uninitialized, introduce 'ocfs2_iocb_init_rw_locked()'and use it from where 'ocfs2_dio_end_io()' might take care, i.e. in'ocfs2_file_read_iter()' and 'ocfs2_file_write_iter()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53158 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()This loop is supposed to break if the frequency returned fromclk_round_rate() is the same as on the previous iteration. However,that check doesn't make sense on the first iteration through the loop.It leads to reading before the start of these->clk_perf_tbl[] array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53161 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/bluefield: Fix potential integer overflowThe 64-bit argument for the "get DIMM info" SMC call consists of mem_ctrl_idxleft-shifted 16 bits and OR-ed with DIMM index. With mem_ctrl_idx defined as32-bits wide the left-shift operation truncates the upper 16 bits ofinformation during the calculation of the SMC argument.The mem_ctrl_idx stack variable must be defined as 64-bits wide to prevent anypotential integer overflow, i.e. loss of data from upper 16 bits.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53213 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: lan78xx: Fix double free issue with interrupt buffer allocationIn lan78xx_probe(), the buffer `buf` was being freed twice: onceimplicitly through `usb_free_urb(dev->urb_intr)` with the`URB_FREE_BUFFER` flag and again explicitly by `kfree(buf)`. This causeda double free issue.To resolve this, reordered `kmalloc()` and `usb_alloc_urb()` calls tosimplify the initialization sequence and removed the redundant`kfree(buf)`. Now, `buf` is allocated after `usb_alloc_urb()`, ensuringit is correctly managed by `usb_fill_int_urb()` and freed by`usb_free_urb()` as intended.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56754 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: caam - Fix the pointer passed to caam_qi_shutdown()The type of the last parameter given to devm_add_action_or_reset() is"struct caam_drv_private *", but in caam_qi_shutdown(), it is casted to"struct device *".Pass the correct parameter to devm_add_action_or_reset() so that theresources are released as expected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56769 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_regSyzbot reports [1] an uninitialized value issue found by KMSAN indib3000_read_reg().Local u8 rb[2] is used in i2c_transfer() as a read buffer; in casethat call fails, the buffer may end up with some undefined values.Since no elaborate error handling is expected in dib3000_write_reg(),simply zero out rb buffer to mitigate the problem.[1] Syzkaller reportdvb-usb: bulk message failed: -22 (6/0)=====================================================BUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110...Local variable rb created at: dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57899 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix mbss changed flags corruption on 32 bit systemsOn 32-bit systems, the size of an unsigned long is 4 bytes,while a u64 is 8 bytes. Therefore, when usingor_each_set_bit(bit, &bits, sizeof(changed) * BITS_PER_BYTE),the code is incorrectly searching for a bit in a 32-bitvariable that is expected to be 64 bits in size,leading to incorrect bit finding.Solution: Ensure that the size of the bits variable is correctlyadjusted for each architecture. Call Trace: ? show_regs+0x54/0x58 ? __warn+0x6b/0xd4 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? report_bug+0x113/0x150 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x44 ? exc_invalid_op+0x18/0x50 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? exc_overflow+0x30/0x30 ? ieee80211_link_info_change_notify+0xcc/0xd4 [mac80211] ? ieee80211_mesh_work+0xff/0x260 [mac80211] ? cfg80211_wiphy_work+0x72/0x98 [cfg80211] ? process_one_work+0xf1/0x1fc ? worker_thread+0x2c0/0x3b4 ? kthread+0xc7/0xf0 ? mod_delayed_work_on+0x4c/0x4c ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork+0x24/0x38 ? kthread_complete_and_exit+0x14/0x14 ? ret_from_fork_asm+0xf/0x14 ? entry_INT80_32+0xf0/0xf0[restore no-op path for no changes]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58096 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: add srng->lock for ath11k_hal_srng_* in monitor modeath11k_hal_srng_* should be used with srng->lock to protect srng data.For ath11k_dp_rx_mon_dest_process() and ath11k_dp_full_mon_process_rx(),they use ath11k_hal_srng_* for many times but never call srng->lock.So when running (full) monitor mode, warning will occur:RIP: 0010:ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k]Call Trace: ? ath11k_hal_srng_dst_peek+0x18/0x30 [ath11k] ath11k_dp_rx_process_mon_status+0xc45/0x1190 [ath11k] ? idr_alloc_u32+0x97/0xd0 ath11k_dp_rx_process_mon_rings+0x32a/0x550 [ath11k] ath11k_dp_service_srng+0x289/0x5a0 [ath11k] ath11k_pcic_ext_grp_napi_poll+0x30/0xd0 [ath11k] __napi_poll+0x30/0x1f0 net_rx_action+0x198/0x320 __do_softirq+0xdd/0x319So add srng->lock for them to avoid such warnings.Inorder to fetch the srng->lock, should change srng's definition from'void' to 'struct hal_srng'. And initialize them elsewhere to preventone line of code from being too long. This is consistent with other ringprocess functions, such as ath11k_dp_process_rx().Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-11412 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability has been found in GNU Binutils 2.45. This impacts the function bfd_elf_gc_record_vtentry of the file bfd/elflink.c of the component Linker. The manipulation leads to out-of-bounds read. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The identifier of the patch is 047435dd988a3975d40c6626a8f739a0b2e154bc. To fix this issue, it is recommended to deploy a patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-11413 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability was found in GNU Binutils 2.45. Affected is the function elf_link_add_object_symbols of the file bfd/elflink.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. Upgrading to version 2.46 is able to address this issue. The patch is identified as 72efdf166aa0ed72ecc69fc2349af6591a7a19c0. Upgrading the affected component is advised.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-11414 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability was determined in GNU Binutils 2.45. Affected by this vulnerability is the function get_link_hash_entry of the file bfd/elflink.c of the component Linker. This manipulation causes out-of-bounds read. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Upgrading to version 2.46 addresses this issue. Patch name: aeaaa9af6359c8e394ce9cf24911fec4f4d23703. It is advisable to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-14104 Severity: Moderate CVSS3 score: 6.1

Description: A flaw was found in util-linux. This vulnerability allows a heap buffer overread when processing 256-byte usernames, specifically within the `setpwnam()` function, affecting SUID (Set User ID) login-utils utilities writing to the password database.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libblkid1 > 0-0 (version in image is 2.37.2-150400.8.35.2).

CVE-2025-21782 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix a oob in orangefs_debug_writeI got a syzbot report: slab-out-of-bounds Read inorangefs_debug_write... several people suggested fixes,I tested Al Viro's suggestion and made this patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21922 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: Fix KMSAN uninit-value warning with bpfSyzbot caught an "KMSAN: uninit-value" warning [1], which is caused by theppp driver not initializing a 2-byte header when using socket filter.The following code can generate a PPP filter BPF program:'''struct bpf_program fp;pcap_t *handle;handle = pcap_open_dead(DLT_PPP_PPPD, 65535);pcap_compile(handle, &fp, "ip and outbound", 0, 0);bpf_dump(&fp, 1);'''Its output is:'''(000) ldh [2](001) jeq #0x21 jt 2 jf 5(002) ldb [0](003) jeq #0x1 jt 4 jf 5(004) ret #65535(005) ret #0'''Wen can find similar code at the following link:https://github.com/ppp-project/ppp/blob/master/pppd/options.c#L1680The maintainer of this code repository is also the original maintainerof the ppp driver.As you can see the BPF program skips 2 bytes of data and then reads the'Protocol' field to determine if it's an IP packet. Then it read the firstbyte of the first 2 bytes to determine the direction.The issue is that only the first byte indicating direction is initializedin current ppp driver code while the second byte is not initialized.For normal BPF programs generated by libpcap, uninitialized data won't beused, so it's not a problem. However, for carefully crafted BPF programs,such as those generated by syzkaller [2], which start reading from offset0, the uninitialized data will be used and caught by KMSAN.[1] https://syzkaller.appspot.com/bug?extid=853242d9c9917165d791[2] https://syzkaller.appspot.com/text?tag=ReproC&x=11994913980000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21962 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing closetimeo mount optionUser-provided mount parameter closetimeo of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22022 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Apply the link chain quirk on NEC isoc endpointsTwo clearly different specimens of NEC uPD720200 (one with start/stopbug, one without) were seen to cause IOMMU faults after some MissedService Errors. Faulting address is immediately after a transfer ringsegment and patched dynamic debug messages revealed that the MSE wasreceived when waiting for a TD near the end of that segment:[ 1.041954] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ffa08fe0[ 1.042120] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09000 flags=0x0000][ 1.042146] xhci_hcd: AMD-Vi: Event logged [IO_PAGE_FAULT domain=0x0005 address=0xffa09040 flags=0x0000]It gets even funnier if the next page is a ring segment accessible tothe HC. Below, it reports MSE in segment at ff1e8000, plows through azero-filled page at ff1e9000 and starts reporting events for TRBs inpage at ff1ea000 every microframe, instead of jumping to seg ff1e6000.[ 7.041671] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.041999] xhci_hcd: Miss service interval error for slot 1 ep 2 expected TD DMA ff1e8fe0[ 7.042011] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042028] xhci_hcd: All TDs skipped for slot 1 ep 2. Clear skip flag.[ 7.042134] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042138] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042144] xhci_hcd: Looking for event-dma 00000000ff1ea040 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.042259] xhci_hcd: WARN: buffer overrun event for slot 1 ep 2 on endpoint[ 7.042262] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 31[ 7.042266] xhci_hcd: Looking for event-dma 00000000ff1ea050 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820At some point completion events change from Isoch Buffer Overrun toShort Packet and the HC finally finds cycle bit mismatch in ff1ec000.[ 7.098130] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098132] xhci_hcd: Looking for event-dma 00000000ff1ecc50 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098254] xhci_hcd: ERROR Transfer event TRB DMA ptr not part of current TD ep_index 2 comp_code 13[ 7.098256] xhci_hcd: Looking for event-dma 00000000ff1ecc60 trb-start 00000000ff1e6820 trb-end 00000000ff1e6820[ 7.098379] xhci_hcd: Overrun event on slot 1 ep 2It's possible that data from the isochronous device were written torandom buffers of pending TDs on other endpoints (either IN or OUT),other devices or even other HCs in the same IOMMU domain.Lastly, an error from a different USB device on another HC. Was itcaused by the above? I don't know, but it may have been. The diskwas working without any other issues and generated PCIe traffic tostarve the NEC of upstream BW and trigger those MSEs. The two HCsshared one x1 slot by means of a commercial "PCIe splitter" board.[ 7.162604] usb 10-2: reset SuperSpeed USB device number 3 using xhci_hcd[ 7.178990] sd 9:0:0:0: [sdb] tag#0 UNKNOWN(0x2003) Result: hostbyte=0x07 driverbyte=DRIVER_OK cmd_age=0s[ 7.179001] sd 9:0:0:0: [sdb] tag#0 CDB: opcode=0x28 28 00 04 02 ae 00 00 02 00 00[ 7.179004] I/O error, dev sdb, sector 67284480 op 0x0:(READ) flags 0x80700 phys_seg 5 prio class 0Fortunately, it appears that this ridiculous bug is avoided by settingthe chain bit of Link TRBs on isochronous rings. Other ancient HCs areknown which also expect the bit to be set and they ignore Link TRBs ifit's not. Reportedly, 0.95 spec guaranteed that the bit is set.The bandwidth-starved NEC HC running a 32KB/uframe UVC endpoint reportstens of MSEs per second and runs into the bug within seconds. ChainingLink TRBs allows the same workload to run for many minutes, many times.No ne---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22035 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix use-after-free in print_graph_function_flags during tracer switchingKairui reported a UAF issue in print_graph_function_flags() duringftrace stress testing [1]. This issue can be reproduced if puting a'mdelay(10)' after 'mutex_unlock(&trace_types_lock)' in s_start(),and executing the following script: $ echo function_graph > current_tracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracerThe root cause lies in the two calls to print_graph_function_flagswithin print_trace_line during each s_show(): * One through 'iter->trace->print_line()'; * Another through 'event->funcs->trace()', which is hidden in print_trace_fmt() before print_trace_line returns.Tracer switching only updates the former, while the latter continuesto use the print_line function of the old tracer, which in the scriptabove is print_graph_function_flags.Moreover, when switching from the 'function_graph' tracer to the'timerlat' tracer, s_start only calls graph_trace_close of the'function_graph' tracer to free 'iter->private', but does not setit to NULL. This provides an opportunity for 'event->funcs->trace()'to use an invalid 'iter->private'.To fix this issue, set 'iter->private' to NULL immediately afterfreeing it in graph_trace_close(), ensuring that an invalid pointeris not passed to other tracers. Additionally, clean up the unnecessary'iter->private = NULL' during each 'cat trace' when using wakeup andirqsoff tracers. [1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22089 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Don't expose hw_counters outside of init net namespaceCommit 467f432a521a ("RDMA/core: Split port and device counter sysfsattributes") accidentally almost exposed hw counters to non-init netnamespaces. It didn't expose them fully, as an attempt to read any ofthose counters leads to a crash like this one:[42021.807566] BUG: kernel NULL pointer dereference, address: 0000000000000028[42021.814463] #PF: supervisor read access in kernel mode[42021.819549] #PF: error_code(0x0000) - not-present page[42021.824636] PGD 0 P4D 0[42021.827145] Oops: 0000 [#1] SMP PTI[42021.830598] CPU: 82 PID: 2843922 Comm: switchto-defaul Kdump: loaded Tainted: G S W I XXX[42021.841697] Hardware name: XXX[42021.849619] RIP: 0010:hw_stat_device_show+0x1e/0x40 [ib_core][42021.855362] Code: 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 49 89 d0 4c 8b 5e 20 48 8b 8f b8 04 00 00 48 81 c7 f0 fa ff ff <48> 8b 41 28 48 29 ce 48 83 c6 d0 48 c1 ee 04 69 d6 ab aa aa aa 48[42021.873931] RSP: 0018:ffff97fe90f03da0 EFLAGS: 00010287[42021.879108] RAX: ffff9406988a8c60 RBX: ffff940e1072d438 RCX: 0000000000000000[42021.886169] RDX: ffff94085f1aa000 RSI: ffff93c6cbbdbcb0 RDI: ffff940c7517aef0[42021.893230] RBP: ffff97fe90f03e70 R08: ffff94085f1aa000 R09: 0000000000000000[42021.900294] R10: ffff94085f1aa000 R11: ffffffffc0775680 R12: ffffffff87ca2530[42021.907355] R13: ffff940651602840 R14: ffff93c6cbbdbcb0 R15: ffff94085f1aa000[42021.914418] FS: 00007fda1a3b9700(0000) GS:ffff94453fb80000(0000) knlGS:0000000000000000[42021.922423] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[42021.928130] CR2: 0000000000000028 CR3: 00000042dcfb8003 CR4: 00000000003726f0[42021.935194] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[42021.942257] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[42021.949324] Call Trace:[42021.951756] [42021.953842] [] ? show_regs+0x64/0x70[42021.959030] [] ? __die+0x78/0xc0[42021.963874] [] ? page_fault_oops+0x2b5/0x3b0[42021.969749] [] ? exc_page_fault+0x1a2/0x3c0[42021.975549] [] ? asm_exc_page_fault+0x26/0x30[42021.981517] [] ? __pfx_show_hw_stats+0x10/0x10 [ib_core][42021.988482] [] ? hw_stat_device_show+0x1e/0x40 [ib_core][42021.995438] [] dev_attr_show+0x1e/0x50[42022.000803] [] sysfs_kf_seq_show+0x81/0xe0[42022.006508] [] seq_read_iter+0xf4/0x410[42022.011954] [] vfs_read+0x16e/0x2f0[42022.017058] [] ksys_read+0x6e/0xe0[42022.022073] [] do_syscall_64+0x6a/0xa0[42022.027441] [] entry_SYSCALL_64_after_hwframe+0x78/0xe2The problem can be reproduced using the following steps: ip netns add foo ip netns exec foo bash cat /sys/class/infiniband/mlx4_0/hw_counters/*The panic occurs because of casting the device pointer into anib_device pointer using container_of() in hw_stat_device_show() iswrong and leads to a memory corruption.However the real problem is that hw counters should never been exposedoutside of the non-init net namespace.Fix this by saving the index of the corresponding attribute group(it might be 1 or 2 depending on the presence of driver-specificattributes) and zeroing the pointer to hw_counters group for compatdevices during the initialization.With this fix applied hw_counters are not available in a non-initnet namespace: find /sys/class/infiniband/mlx4_0/ -name hw_counters /sys/class/infiniband/mlx4_0/ports/1/hw_counters /sys/class/infiniband/mlx4_0/ports/2/hw_counters /sys/class/infiniband/mlx4_0/hw_counters ip netns add foo ip netns exec foo bash find /sys/class/infiniband/mlx4_0/ -name hw_counters

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Use kernel helpers for hex dumpsPreviously, when the driver was printing hex dumps, the buffer was castto an 8 byte long and printed using string formatters. If the buffersize was not a multiple of 8 then a read buffer overflow was possible.Therefore, create a new ibmvnic function that loops over a buffer andcalls hex_dump_to_buffer instead.This patch address KASAN reports like the one below: ibmvnic 30000003 env3: Login Buffer: ibmvnic 30000003 env3: 01000000af000000 <...> ibmvnic 30000003 env3: 2e6d62692e736261 ibmvnic 30000003 env3: 65050003006d6f63 ================================================================== BUG: KASAN: slab-out-of-bounds in ibmvnic_login+0xacc/0xffc [ibmvnic] Read of size 8 at addr c0000001331a9aa8 by task ip/17681 <...> Allocated by task 17681: <...> ibmvnic_login+0x2f0/0xffc [ibmvnic] ibmvnic_open+0x148/0x308 [ibmvnic] __dev_open+0x1ac/0x304 <...> The buggy address is located 168 bytes inside of allocated 175-byte region [c0000001331a9a00, c0000001331a9aaf) <...> ================================================================= ibmvnic 30000003 env3: 000000000033766e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37749 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: ppp: Add bound checking for skb data on ppp_sync_txmungEnsure we have enough data in linear buffer from skb before accessinginitial bytes. This prevents potential out-of-bounds accesseswhen processing short packets.When ppp_sync_txmung receives an incoming package with an emptypayload:(remote) gef>> p *(struct pppoe_hdr *) (skb->head + skb->network_header)$18 = { type = 0x1, ver = 0x1, code = 0x0, sid = 0x2, length = 0x0, tag = 0xffff8880371cdb96}from the skb struct (trimmed) tail = 0x16, end = 0x140, head = 0xffff88803346f400 "4", data = 0xffff88803346f416 ":\377", truesize = 0x380, len = 0x0, data_len = 0x0, mac_len = 0xe, hdr_len = 0x0,it is not safe to access data[2].[pabeni@redhat.com: fixed subj typo]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37782 Severity: Moderate CVSS3 score: 6.1

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38031 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:padata: do not leak refcount in reorder_workA recent patch that addressed a UAF introduced a reference count leak:the parallel_data refcount is incremented unconditionally, regardlessof the return value of queue_work(). If the work item is already queued,the incremented refcount is never decremented.Fix this by checking the return value of queue_work() and decrementingthe refcount when necessary.Resolves:Unreferenced object 0xffff9d9f421e3d80 (size 192): comm "cryptomgr_probe", pid 157, jiffies 4294694003 hex dump (first 32 bytes): 80 8b cf 41 9f 9d ff ff b8 97 e0 89 ff ff ff ff ...A............ d0 97 e0 89 ff ff ff ff 19 00 00 00 1f 88 23 00 ..............#. backtrace (crc 838fb36): __kmalloc_cache_noprof+0x284/0x320 padata_alloc_pd+0x20/0x1e0 padata_alloc_shell+0x3b/0xa0 0xffffffffc040a54d cryptomgr_probe+0x43/0xc0 kthread+0xf6/0x1f0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38068 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lzo - Fix compression buffer overrunUnlike the decompression code, the compression code in LZO neverchecked for output overruns. It instead assumes that the calleralways provides enough buffer space, disregarding the buffer lengthprovided by the caller.Add a safe compression interface that checks for the end of bufferbefore each write. Use the safe interface in crypto/lzo.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38192 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: clear the dst when changing skb protocolA not-so-careful NAT46 BPF program can crash the kernelif it indiscriminately flips ingress packets from v4 to v6: BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6_rcv_core (net/ipv6/ip6_input.c:190:20) ipv6_rcv (net/ipv6/ip6_input.c:306:8) process_backlog (net/core/dev.c:6186:4) napi_poll (net/core/dev.c:6906:9) net_rx_action (net/core/dev.c:7028:13) do_softirq (kernel/softirq.c:462:3) netif_rx (net/core/dev.c:5326:3) dev_loopback_xmit (net/core/dev.c:4015:2) ip_mc_finish_output (net/ipv4/ip_output.c:363:8) NF_HOOK (./include/linux/netfilter.h:314:9) ip_mc_output (net/ipv4/ip_output.c:400:5) dst_output (./include/net/dst.h:459:9) ip_local_out (net/ipv4/ip_output.c:130:9) ip_send_skb (net/ipv4/ip_output.c:1496:8) udp_send_skb (net/ipv4/udp.c:1040:8) udp_sendmsg (net/ipv4/udp.c:1328:10)The output interface has a 4->6 program attached at ingress.We try to loop the multicast skb back to the sending socket.Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdrand changes skb->protocol to v6. We enter ip6_rcv_core whichtries to use skb_dst(). But the dst is still an IPv4 one leftafter IPv4 mcast output.Clear the dst in all BPF helpers which change the protocol.Try to preserve metadata dsts, those may carry non-routingmetadata.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38193 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: reject invalid perturb periodGerrard Tai reported that SFQ perturb_period has no range check yet,and this can be used to trigger a race condition fixed in a separate patch.We want to make sure ctl->perturb_period * HZ will not overflowand is positive.tc qd add dev lo root sfq perturb -10 # negative value : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 1000000000 # too big : errorError: sch_sfq: invalid perturb period.tc qd add dev lo root sfq perturb 2000000 # acceptable valuetc -s -d qd sh dev loqdisc sfq 8005: root refcnt 2 limit 127p quantum 64Kb depth 127 flows 128 divisor 1024 perturb 2000000sec Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38197 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell_rbu: Fix list usagePass the correct list head to list_for_each_entry*() when looping throughthe packet list.Without this patch, reading the packet data via sysfs will show the dataincorrectly (because it starts at the wrong packet), and clearing thepacket list will result in a NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38211 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix use-after-free of work objects after cm_id destructionThe commit 59c68ac31e15 ("iw_cm: free cm_id resources on the lastderef") simplified cm_id resource management by freeing cm_id once allreferences to the cm_id were removed. The references are removed eitherupon completion of iw_cm event handlers or when the application destroysthe cm_id. This commit introduced the use-after-free condition wherecm_id_private object could still be in use by event handler works duringthe destruction of cm_id. The commit aee2424246f9 ("RDMA/iwcm: Fix ause-after-free related to destroying CM IDs") addressed this use-after-free by flushing all pending works at the cm_id destruction.However, still another use-after-free possibility remained. It happenswith the work objects allocated for each cm_id_priv withinalloc_work_entries() during cm_id creation, and subsequently freed indealloc_work_entries() once all references to the cm_id are removed.If the cm_id's last reference is decremented in the event handler work,the work object for the work itself gets removed, and causes the use-after-free BUG below: BUG: KASAN: slab-use-after-free in __pwq_activate_work+0x1ff/0x250 Read of size 8 at addr ffff88811f9cf800 by task kworker/u16:1/147091 CPU: 2 UID: 0 PID: 147091 Comm: kworker/u16:1 Not tainted 6.15.0-rc2+ #27 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014 Workqueue: 0x0 (iw_cm_wq) Call Trace: dump_stack_lvl+0x6a/0x90 print_report+0x174/0x554 ? __virt_addr_valid+0x208/0x430 ? __pwq_activate_work+0x1ff/0x250 kasan_report+0xae/0x170 ? __pwq_activate_work+0x1ff/0x250 __pwq_activate_work+0x1ff/0x250 pwq_dec_nr_in_flight+0x8c5/0xfb0 process_one_work+0xc11/0x1460 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x16c/0x240 worker_thread+0x5ef/0xfd0 ? __pfx_worker_thread+0x10/0x10 kthread+0x3b0/0x770 ? __pfx_kthread+0x10/0x10 ? rcu_is_watching+0x11/0xb0 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 147416: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 __kasan_kmalloc+0xa6/0xb0 alloc_work_entries+0xa9/0x260 [iw_cm] iw_cm_connect+0x23/0x4a0 [iw_cm] rdma_connect_locked+0xbfd/0x1920 [rdma_cm] nvme_rdma_cm_handler+0x8e5/0x1b60 [nvme_rdma] cma_cm_event_handler+0xae/0x320 [rdma_cm] cma_work_handler+0x106/0x1b0 [rdma_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 147091: kasan_save_stack+0x2c/0x50 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x60 __kasan_slab_free+0x4b/0x70 kfree+0x13a/0x4b0 dealloc_work_entries+0x125/0x1f0 [iw_cm] iwcm_deref_id+0x6f/0xa0 [iw_cm] cm_work_handler+0x136/0x1ba0 [iw_cm] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30 Last potentially related work creation: kasan_save_stack+0x2c/0x50 kasan_record_aux_stack+0xa3/0xb0 __queue_work+0x2ff/0x1390 queue_work_on+0x67/0xc0 cm_event_handler+0x46a/0x820 [iw_cm] siw_cm_upcall+0x330/0x650 [siw] siw_cm_work_handler+0x6b9/0x2b20 [siw] process_one_work+0x84f/0x1460 worker_thread+0x5ef/0xfd0 kthread+0x3b0/0x770 ret_from_fork+0x30/0x70 ret_from_fork_asm+0x1a/0x30This BUG is reproducible by repeating the blktests test case nvme/061for the rdma transport and the siw driver.To avoid the use-after-free of cm_id_private work objects, ensure thatthe last reference to the cm_id is decremented not in the event handlerworks, but in the cm_id destruction context. For that purpose, mo---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38222 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: inline: fix len overflow in ext4_prepare_inline_dataWhen running the following code on an ext4 filesystem with inline_datafeature enabled, it will lead to the bug below. fd = open("file1", O_RDWR | O_CREAT | O_TRUNC, 0666); ftruncate(fd, 30); pwrite(fd, "a", 1, (1UL << 40) + 5UL);That happens because write_begin will succeed as whenext4_generic_write_inline_data calls ext4_prepare_inline_data, pos + lenwill be truncated, leading to ext4_prepare_inline_data parameter to be 6instead of 0x10000000006.Then, later when write_end is called, we hit: BUG_ON(pos + len > EXT4_I(inode)->i_inline_size);at ext4_write_inline_data.Fix it by using a loff_t type for the len parameter inext4_prepare_inline_data instead of an unsigned int.[ 44.545164] ------------[ cut here ]------------[ 44.545530] kernel BUG at fs/ext4/inline.c:240![ 44.545834] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 44.546172] CPU: 3 UID: 0 PID: 343 Comm: test Not tainted 6.15.0-rc2-00003-g9080916f4863 #45 PREEMPT(full) 112853fcebfdb93254270a7959841d2c6aa2c8bb[ 44.546523] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 44.546523] RIP: 0010:ext4_write_inline_data+0xfe/0x100[ 44.546523] Code: 3c 0e 48 83 c7 48 48 89 de 5b 41 5c 41 5d 41 5e 41 5f 5d e9 e4 fa 43 01 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc 0f 0b <0f> 0b 0f 1f 44 00 00 55 41 57 41 56 41 55 41 54 53 48 83 ec 20 49[ 44.546523] RSP: 0018:ffffb342008b79a8 EFLAGS: 00010216[ 44.546523] RAX: 0000000000000001 RBX: ffff9329c579c000 RCX: 0000010000000006[ 44.546523] RDX: 000000000000003c RSI: ffffb342008b79f0 RDI: ffff9329c158e738[ 44.546523] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000[ 44.546523] R10: 00007ffffffff000 R11: ffffffff9bd0d910 R12: 0000006210000000[ 44.546523] R13: fffffc7e4015e700 R14: 0000010000000005 R15: ffff9329c158e738[ 44.546523] FS: 00007f4299934740(0000) GS:ffff932a60179000(0000) knlGS:0000000000000000[ 44.546523] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 44.546523] CR2: 00007f4299a1ec90 CR3: 0000000002886002 CR4: 0000000000770eb0[ 44.546523] PKRU: 55555554[ 44.546523] Call Trace:[ 44.546523] [ 44.546523] ext4_write_inline_data_end+0x126/0x2d0[ 44.546523] generic_perform_write+0x17e/0x270[ 44.546523] ext4_buffered_write_iter+0xc8/0x170[ 44.546523] vfs_write+0x2be/0x3e0[ 44.546523] __x64_sys_pwrite64+0x6d/0xc0[ 44.546523] do_syscall_64+0x6a/0xf0[ 44.546523] ? __wake_up+0x89/0xb0[ 44.546523] ? xas_find+0x72/0x1c0[ 44.546523] ? next_uptodate_folio+0x317/0x330[ 44.546523] ? set_pte_range+0x1a6/0x270[ 44.546523] ? filemap_map_pages+0x6ee/0x840[ 44.546523] ? ext4_setattr+0x2fa/0x750[ 44.546523] ? do_pte_missing+0x128/0xf70[ 44.546523] ? security_inode_post_setattr+0x3e/0xd0[ 44.546523] ? ___pte_offset_map+0x19/0x100[ 44.546523] ? handle_mm_fault+0x721/0xa10[ 44.546523] ? do_user_addr_fault+0x197/0x730[ 44.546523] ? do_syscall_64+0x76/0xf0[ 44.546523] ? arch_exit_to_user_mode_prepare+0x1e/0x60[ 44.546523] ? irqentry_exit_to_user_mode+0x79/0x90[ 44.546523] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 44.546523] RIP: 0033:0x7f42999c6687[ 44.546523] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff[ 44.546523] RSP: 002b:00007ffeae4a7930 EFLAGS: 00000202 ORIG_RAX: 0000000000000012[ 44.546523] RAX: ffffffffffffffda RBX: 00007f4299934740 RCX: 00007f42999c6687[ 44.546523] RDX: 0000000000000001 RSI: 000055ea6149200f RDI: 0000000000000003[ 44.546523] RBP: 00007ffeae4a79a0 R08: 0000000000000000 R09: 0000000000000000[ 44.546523] R10: 0000010000000005 R11: 0000000000000202 R12: 0000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38249 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix out-of-bounds read in snd_usb_get_audioformat_uac3()In snd_usb_get_audioformat_uac3(), the length value returned fromsnd_usb_ctl_msg() is used directly for memory allocation withoutvalidation. This length is controlled by the USB device.The allocated buffer is cast to a uac3_cluster_header_descriptorand its fields are accessed without verifying that the bufferis large enough. If the device returns a smaller than expectedlength, this leads to an out-of-bounds read.Add a length check to ensure the buffer is large enough foruac3_cluster_header_descriptor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38310 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: Fix validation of nexthop addressesThe kernel currently validates that the length of the provided nexthopaddress does not exceed the specified length. This can lead to thekernel reading uninitialized memory if user space provided a shorterlength than the specified one.Fix by validating that the provided length exactly matches the specifiedone.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38334 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Prevent attempts to reclaim poisoned pagesTL;DR: SGX page reclaim touches the page to copy its contents tosecondary storage. SGX instructions do not gracefully handle machinechecks. Despite this, the existing SGX code will try to reclaim pagesthat it _knows_ are poisoned. Avoid even trying to reclaim poisoned pages.The longer story:Pages used by an enclave only get epc_page->poison set inarch_memory_failure() but they currently stay on sgx_active_page_list untilsgx_encl_release(), with the SGX_EPC_PAGE_RECLAIMER_TRACKED flag untouched.epc_page->poison is not checked in the reclaimer logic meaning that, if otherconditions are met, an attempt will be made to reclaim an EPC page that waspoisoned. This is bad because 1. we don't want that page to end up addedto another enclave and 2. it is likely to cause one core to shut downand the kernel to panic.Specifically, reclaiming uses microcode operations including "EWB" whichaccesses the EPC page contents to encrypt and write them out to non-SGXmemory. Those operations cannot handle MCEs in their accesses other thanby putting the executing core into a special shutdown state (affectingboth threads with HT.) The kernel will subsequently panic on theremaining cores seeing the core didn't enter MCE handler(s) in time.Call sgx_unmark_page_reclaimable() to remove the affected EPC page fromsgx_active_page_list on memory error to stop it being considered forreclaiming.Testing epc_page->poison in sgx_reclaim_pages() would also work but I assumeit's better to add code in the less likely paths.The affected EPC page is not added to &node->sgx_poison_page_list untillater in sgx_encl_release()->sgx_free_epc_page() when it is EREMOVEd.Membership on other lists doesn't change to avoid changing any of thelists' semantics except for sgx_active_page_list. There's a "TBD" commentin arch_memory_failure() about pre-emptive actions, the goal here is notto address everything that it may imply.This also doesn't completely close the time window when a memory errornotification will be fatal (for a not previously poisoned EPC page) --the MCE can happen after sgx_reclaim_pages() has selected its candidatesor even *inside* a microcode operation (actually easy to trigger due tothe amount of time spent in them.)The spinlock in sgx_unmark_page_reclaimable() is safe becausememory_failure() runs in process context and no spinlocks are held,explicitly noted in a mm/memory-failure.c comment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38403 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/vmci: Clear the vmci transport packet properly when initializing itIn vmci_transport_packet_init memset the vmci_transport_packet beforepopulating the fields to avoid any uninitialised data being left in thestructure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38425 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: check msg length in SMBUS block readFor SMBUS block read, do not continue to read if the message lengthpassed from the device is '0' or greater than the maximum allowed bytes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38443 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_genl_connect() error pathThere is a use-after-free issue in nbd:block nbd6: Receive control failed (result -104)block nbd6: shutting down sockets==================================================================BUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022Write of size 4 at addr ffff8880295de478 by task kworker/u33:0/67CPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: nbd6-recv recv_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline] recv_work+0x694/0xa80 drivers/block/nbd.c:1022 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 nbd_genl_connect() does not properly stop the device on certainerror paths after nbd_start_device() has been called. This causesthe error path to put nbd->config while recv_work continue to usethe config after putting it, leading to use-after-free in recv_work.This patch moves nbd_start_device() after the backend file creation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38502 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix oob access in cgroup local storageLonial reported that an out-of-bounds access in cgroup local storagecan be crafted via tail calls. Given two programs each utilizing acgroup local storage with a different value size, and one programdoing a tail call into the other. The verifier will validate each ofthe indivial programs just fine. However, in the runtime contextthe bpf_cg_run_ctx holds an bpf_prog_array_item which contains theBPF program as well as any cgroup local storage flavor the programuses. Helpers such as bpf_get_local_storage() pick this up from theruntime context: ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx); storage = ctx->prog_item->cgroup_storage[stype]; if (stype == BPF_CGROUP_STORAGE_SHARED) ptr = &READ_ONCE(storage->buf)->data[0]; else ptr = this_cpu_ptr(storage->percpu_buf);For the second program which was called from the originally attachedone, this means bpf_get_local_storage() will pick up the formerprogram's map, not its own. With mismatching sizes, this can resultin an unintended out-of-bounds access.To fix this issue, we need to extend bpf_map_owner with an array ofstorage_cookie[] to match on i) the exact maps from the originalprogram if the second program was using bpf_get_local_storage(), orii) allow the tail call combination if the second program was notusing any of the cgroup local storage maps.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38529 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: aio_iiro_16: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38530 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl812: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: if ((1 << it->options[1]) & board->irq_bits) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38531 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:iio: common: st_sensors: Fix use of uninitialize device structsThroughout the various probe functions &indio_dev->dev is used before itis initialized. This caused a kernel panic in st_sensors_power_enable()when the call to devm_regulator_bulk_get_enable() fails and then callsdev_err_probe() with the uninitialized device.This seems to only cause a panic with dev_err_probe(), dev_err(),dev_warn() and dev_info() don't seem to cause a panic, but are fixedas well.The issue is reported and traced here: [1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38542 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: appletalk: Fix device refcount leak in atrtr_create()When updating an existing route entry in atrtr_create(), the old devicereference was not being released before assigning the new device,leading to a device refcount leak. Fix this by calling dev_put() torelease the old device reference before holding the new one.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38639 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xt_nfacct: don't assume acct name is null-terminatedBUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851[..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523nfnl_acct_find_get() handles non-null input, but the errorprintk relied on its presence.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39716 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:parisc: Revise __get_user() to probe user read accessBecause of the way read access support is implemented, read accessinterruptions are only triggered at privilege levels 2 and 3. Thekernel executes at privilege level 0, so __get_user() never triggersa read access interruption (code 26). Thus, it is currently possiblefor user code to access a read protected address via a system call.Fix this by probing read access rights at privilege level 3 (PRIV_USER)and setting __gu_err to -EFAULT (-14) if access isn't allowed.Note the cmpiclr instruction does a 32-bit compare because COND macrodoesn't work inside asm.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39923 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/eesWhen we don't have a clock specified in the device tree, we have no way toensure the BAM is on. This is often the case for remotely-controlled orremotely-powered BAM instances. In this case, we need to read num-channelsfrom the DT to have all the necessary information to complete probing.However, at the moment invalid device trees without clock and withoutnum-channels still continue probing, because the error handling is missingreturn statements. The driver will then later try to read the number ofchannels from the registers. This is unsafe, because it relies on bootfirmware and lucky timing to succeed. Unfortunately, the lack of propererror handling here has been abused for several Qualcomm SoCs upstream,causing early boot crashes in several situations [1, 2].Avoid these early crashes by erroring out when any of the required DTproperties are missing. Note that this will break some of the existing DTsupstream (mainly BAM instances related to the crypto engine). However,clearly these DTs have never been tested properly, since the error in thekernel log was just ignored. It's safer to disable the crypto engine forthese broken DTBs.[1]: https://lore.kernel.org/r/CY01EKQVWE36.B9X5TDXAREPF@fairphone.com/[2]: https://lore.kernel.org/r/20230626145959.646747-1-krzysztof.kozlowski@linaro.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39949 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:qed: Don't collect too many protection override GRC elementsIn the protection override dump path, the firmware can return far toomany GRC elements, resulting in attempting to write past the end of thepreviously-kmalloc'ed dump buffer.This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESSwhere "ADDRESS" is just past the end of the protection override dumpbuffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_bufand the size of the buffer is buf_size in the same data structure.The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [qed] qed_hw_err_notify at ffffffffc06d32d7 [qed] qed_spq_post at ffffffffc06b1011 [qed] qed_fcoe_destroy_conn at ffffffffc06b2e91 [qed] qedf_cleanup_fcport at ffffffffc05e7597 [qedf] qedf_rport_event_handler at ffffffffc05e7bf7 [qedf] fc_rport_work at ffffffffc02da715 [libfc] process_one_work at ffffffff8a319663Resolve this by clamping the firmware's return value to the maximumnumber of legal elements the firmware should return.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39955 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().syzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rskin the TCP_ESTABLISHED state. [0]syzbot reused the server-side TCP Fast Open socket as a new client beforethe TFO socket completes 3WHS: 1. accept() 2. connect(AF_UNSPEC) 3. connect() to another destinationAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changesit to TCP_CLOSE and makes connect() possible, which restarts timers.Since tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, theretransmit timer triggered the warning and the intended packet was notretransmitted.Let's call reqsk_fastopen_remove() in tcp_disconnect().[0]:WARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Modules linked in:CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))Code: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3eRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293RAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017RDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400RBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8R10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540R13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0FS: 0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0Call Trace: tcp_write_timer (net/ipv4/tcp_timer.c:738) call_timer_fn (kernel/time/timer.c:1747) __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372) timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135) tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035) __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1)) tmigr_handle_remote (kernel/time/timer_migration.c:1096) handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580) irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39967 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: fix integer overflow in fbcon_do_set_fontFix integer overflow vulnerabilities in fbcon_do_set_font() where fontsize calculations could overflow when handling user-controlled fontparameters.The vulnerabilities occur when:1. CALC_FONTSZ(h, pitch, charcount) performs h * pith * charcount multiplication with user-controlled values that can overflow.2. FONT_EXTRA_WORDS * sizeof(int) + size addition can also overflow3. This results in smaller allocations than expected, leading to buffer overflows during font data copying.Add explicit overflow checking using check_mul_overflow() andcheck_add_overflow() kernel helpers to safety validate all sizecalculations before allocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39970 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix input validation logic for action_metaFix condition to check 'greater or equal' to prevent OOB dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39998 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: target_core_configfs: Add length check to avoid buffer overflowA buffer overflow arises from the usage of snprintf to write into thebuffer "buf" in target_lu_gp_members_show function located in/drivers/target/target_core_configfs.c. This buffer is allocated withsize LU_GROUP_NAME_BUF (256 bytes).snprintf(...) formats multiple strings into buf with the HBA name(hba->hba_group.cg_item), a slash character, a devicename (dev->dev_group.cg_item) and a newline character, the total formatted stringlength may exceed the buffer size of 256 bytes.Since snprintf() returns the total number of bytes that would have beenwritten (the length of %s/%sn ), this value may exceed the buffer length(256 bytes) passed to memcpy(), this will ultimately cause functionmemcpy reporting a buffer overflow error.An additional check of the return value of snprintf() can avoid thisbuffer overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40049 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: fix uninit-value in squashfs_get_parentSyzkaller reports a "KMSAN: uninit-value in squashfs_get_parent" bug.This is caused by open_by_handle_at() being called with a file handlecontaining an invalid parent inode number. In particular the inode numberis that of a symbolic link, rather than a directory.Squashfs_get_parent() gets called with that symbolic link inode, andaccesses the parent member field. unsigned int parent_ino = squashfs_i(inode)->parent;Because non-directory inodes in Squashfs do not have a parent value, thisis uninitialised, and this causes an uninitialised value access.The fix is to initialise parent with the invalid inode 0, which will causean EINVAL error to be returned.Regular inodes used to share the parent field with the block_list_startfield. This is removed in this commit to enable the parent field tocontain the invalid inode number 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40085 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer deference in try_to_register_cardIn try_to_register_card(), the return value of usb_ifnum_to_if() ispassed directly to usb_interface_claimed() without a NULL check, whichwill lead to a NULL pointer dereference when creating an invalidUSB audio device. Fix this by adding a check to ensure the interfacepointer is valid before passing it to usb_interface_claimed().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40126 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARCThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. This commit fixes a couple of badcalculations. This will fix the return value of copy_from_user andcopy_to_user in the faulting case. The behaviour of memcpy stays unchanged.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40135 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU in ip6_xmit()Use RCU in ip6_xmit() in order to use dst_dev_rcu() to preventpossible UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40190 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: guard against EA inode refcount underflow in xattr updatesyzkaller found a path where ext4_xattr_inode_update_ref() reads an EAinode refcount that is already <= 0 and then applies ref_change (often-1). That lets the refcount underflow and we proceed with a bogus value,triggering errors like: EXT4-fs error: EA inode ref underflow: ref_count=-1 ref_change=-1 EXT4-fs warning: ea_inode dec ref err=-117Make the invariant explicit: if the current refcount is non-positive,treat this as on-disk corruption, emit ext4_error_inode(), and fail theoperation with -EFSCORRUPTED instead of updating the refcount. Delete theWARN_ONCE() as negative refcounts are now impossible; keep error reportingin ext4_error_inode().This prevents the underflow and the follow-on orphan/cleanup churn.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40220 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:fuse: fix livelock in synchronous file put from fuseblk workersI observed a hang when running generic/323 against a fuseblk server.This test opens a file, initiates a lot of AIO writes to that filedescriptor, and closes the file descriptor before the writes complete.Unsurprisingly, the AIO exerciser threads are mostly stuck waiting forresponses from the fuseblk server:# cat /proc/372265/task/372313/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_do_getattr+0xfc/0x1f0 [fuse][<0>] fuse_file_read_iter+0xbe/0x1c0 [fuse][<0>] aio_read+0x130/0x1e0[<0>] io_submit_one+0x542/0x860[<0>] __x64_sys_io_submit+0x98/0x1a0[<0>] do_syscall_64+0x37/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53But the /weird/ part is that the fuseblk server threads are waiting forresponses from itself:# cat /proc/372210/task/372232/stack[<0>] request_wait_answer+0x1fe/0x2a0 [fuse][<0>] __fuse_simple_request+0xd3/0x2b0 [fuse][<0>] fuse_file_put+0x9a/0xd0 [fuse][<0>] fuse_release+0x36/0x50 [fuse][<0>] __fput+0xec/0x2b0[<0>] task_work_run+0x55/0x90[<0>] syscall_exit_to_user_mode+0xe9/0x100[<0>] do_syscall_64+0x43/0xf0[<0>] entry_SYSCALL_64_after_hwframe+0x4b/0x53The fuseblk server is fuse2fs so there's nothing all that exciting inthe server itself. So why is the fuse server calling fuse_file_put?The commit message for the fstest sheds some light on that:"By closing the file descriptor before calling io_destroy, you prettymuch guarantee that the last put on the ioctx will be done in interruptcontext (during I/O completion).Aha. AIO fgets a new struct file from the fd when it queues the ioctx.The completion of the FUSE_WRITE command from userspace causes the fuseserver to call the AIO completion function. The completion puts thestruct file, queuing a delayed fput to the fuse server task. When thefuse server task returns to userspace, it has to run the delayed fput,which in the case of a fuseblk server, it does synchronously.Sending the FUSE_RELEASE command sychronously from fuse server threadsis a bad idea because a client program can initiate enough simultaneousAIOs such that all the fuse server threads end up in delayed_fput, andnow there aren't any threads left to handle the queued fuse commands.Fix this by only using asynchronous fputs when closing files, and leavea comment explaining why.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40314 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadgetIn the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadgetstructure (pdev->gadget) was freed before its endpoints.The endpoints are linked via the ep_list in the gadget structure.Freeing the gadget first leaves dangling pointers in the endpoint list.When the endpoints are subsequently freed, this results in a use-after-free.Fix:By separating the usb_del_gadget_udc() operation into distinct "del" and"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to thefinal release of the gadget structure with usb_put_gadget().A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure only after freeing endpoints").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68183 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ima: don't clear IMA_DIGSIG flag when setting or removing non-IMA xattrCurrently when both IMA and EVM are in fix mode, the IMA signature willbe reset to IMA hash if a program first stores IMA signature insecurity.ima and then writes/removes some other security xattr for thefile.For example, on Fedora, after booting the kernel with "ima_appraise=fixevm=fix ima_policy=appraise_tcb" and installing rpm-plugin-ima,installing/reinstalling a package will not make good reference IMAsignature generated. Instead IMA hash is generated, # getfattr -m - -d -e hex /usr/bin/bash # file: usr/bin/bash security.ima=0x0404...This happens because when setting security.selinux, the IMA_DIGSIG flagthat had been set early was cleared. As a result, IMA hash is generatedwhen the file is closed.Similarly, IMA signature can be cleared on file close after removingsecurity xattr like security.evm or setting/removing ACL.Prevent replacing the IMA file signature with a file hash, by preventingthe IMA_DIGSIG flag from being reset.Here's a minimal C reproducer which sets security.selinux as the laststep which can also replaced by removing security.evm or setting ACL, #include #include #include #include #include #include int main() { const char* file_path = "/usr/sbin/test_binary"; const char* hex_string = "030204d33204490066306402304"; int length = strlen(hex_string); char* ima_attr_value; int fd; fd = open(file_path, O_WRONLY|O_CREAT|O_EXCL, 0644); if (fd == -1) { perror("Error opening file"); return 1; } ima_attr_value = (char*)malloc(length / 2 ); for (int i = 0, j = 0; i < length; i += 2, j++) { sscanf(hex_string + i, "%2hhx", &ima_attr_value[j]); } if (fsetxattr(fd, "security.ima", ima_attr_value, length/2, 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } const char* selinux_value= "system_u:object_r:bin_t:s0"; if (fsetxattr(fd, "security.selinux", selinux_value, strlen(selinux_value), 0) == -1) { perror("Error setting extended attribute"); close(fd); return 1; } close(fd); return 0; }

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68328 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: stratix10-svc: fix bug in saving controller dataFix the incorrect usage of platform_set_drvdata and dev_set_drvdata. Theyboth are of the same data and overrides each other. This resulted in thermmod of the svc driver to fail and throw a kernel panic for kthread_stopand fifo free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68342 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing dataThe URB received in gs_usb_receive_bulk_callback() contains a structgs_host_frame. The length of the data after the header depends on thegs_host_frame hf::flags and the active device features (e.g. timestamping).Introduce a new function gs_usb_get_minimum_length() and check that we haveat least received the required amount of data before accessing it. Onlycopy the data to that skb that has actually been received.[mkl: rename gs_usb_get_minimum_length() -> +gs_usb_get_minimum_rx_length()]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68343 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_receive_bulk_callback(): check actual_length before accessing headerThe driver expects to receive a struct gs_host_frame ings_usb_receive_bulk_callback().Use struct_group to describe the header of the struct gs_host_frame andcheck that we have at least received the header before accessing anymembers of it.To resubmit the URB, do not dereference the pointer chain"dev->parent->hf_size_rx" but use "parent->hf_size_rx" instead. Since"urb->context" contains "parent", it is always defined, while "dev" is notdefined if the URB it too short.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68758 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led-bl: Add devlink to supplier LEDsLED Backlight is a consumer of one or multiple LED class devices, butdevlink is currently unable to create correct supplier-producer links whenthe supplier is a class device. It creates instead a link where thesupplier is the parent of the expected device.One consequence is that removal order is not correctly enforced.Issues happen for example with the following sections in a device treeoverlay: // An LED driver chip pca9632@62 { compatible = "nxp,pca9632"; reg = <0x62>; // ... addon_led_pwm: led-pwm@3 { reg = <3>; label = "addon:led:pwm"; }; }; backlight-addon { compatible = "led-backlight"; leds = <&addon_led_pwm>; brightness-levels = <255>; default-brightness-level = <255>; };In this example, the devlink should be created between the backlight-addon(consumer) and the pca9632@62 (supplier). Instead it is created between thebacklight-addon (consumer) and the parent of the pca9632@62, which istypically the I2C bus adapter.On removal of the above overlay, the LED driver can be removed before thebacklight device, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 ... Call trace: led_put+0xe0/0x140 devm_led_release+0x6c/0x98Another way to reproduce the bug without any device tree overlays isunbinding the LED class device (pca9632@62) before unbinding the consumer(backlight-addon): echo 11-0062 >/sys/bus/i2c/drivers/leds-pca963x/unbind echo ...backlight-dock >/sys/bus/platform/drivers/led-backlight/unbindFix by adding a devlink between the consuming led-backlight device and thesupplying LED device, as other drivers and subsystems do as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71114 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:via_wdt: fix critical boot hang due to unnamed resource allocationThe VIA watchdog driver uses allocate_resource() to reserve a MMIOregion for the watchdog control register. However, the allocatedresource was not given a name, which causes the kernel resource treeto contain an entry marked as "" under /proc/iomem on x86platforms.During boot, this unnamed resource can lead to a critical hang becausesubsequent resource lookups and conflict checks fail to handle theinvalid entry properly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-7545 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability classified as problematic was found in GNU Binutils 2.45. Affected by this vulnerability is the function copy_section of the file binutils/objcopy.c. The manipulation leads to heap-based buffer overflow. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The patch is named 08c3cbe5926e4d355b5cb70bbec2b1eeb40c2944. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-7546 Severity: Moderate CVSS3 score: 6.1

Description: A vulnerability, which was classified as problematic, has been found in GNU Binutils 2.45. Affected by this issue is the function bfd_elf_set_group_contents of the file bfd/elf.c. The manipulation leads to out-of-bounds write. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. The name of the patch is 41461010eb7c79fee7a9d5f6209accdaac66cc6b. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2026-22977 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: sock: fix hardened usercopy panic in sock_recv_errqueueskbuff_fclone_cache was created without defining a usercopy region,[1] unlike skbuff_head_cache which properly whitelists the cb[] field.[2] This causes a usercopy BUG() when CONFIG_HARDENED_USERCOPY isenabled and the kernel attempts to copy sk_buff.cb data to userspacevia sock_recv_errqueue() -> put_cmsg().The crash occurs when: 1. TCP allocates an skb using alloc_skb_fclone() (from skbuff_fclone_cache) [1]2. The skb is cloned via skb_clone() using the pre-allocated fclone[3] 3. The cloned skb is queued to sk_error_queue for timestampreporting 4. Userspace reads the error queue via recvmsg(MSG_ERRQUEUE)5. sock_recv_errqueue() calls put_cmsg() to copy serr->ee from skb->cb[4] 6. __check_heap_object() fails because skbuff_fclone_cache has no usercopy whitelist [5]When cloned skbs allocated from skbuff_fclone_cache are used in thesocket error queue, accessing the sock_exterr_skb structure in skb->cbvia put_cmsg() triggers a usercopy hardening violation:[ 5.379589] usercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_fclone_cache' (offset 296, size 16)![ 5.382796] kernel BUG at mm/usercopy.c:102![ 5.383923] Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI[ 5.384903] CPU: 1 UID: 0 PID: 138 Comm: poc_put_cmsg Not tainted 6.12.57 #7[ 5.384903] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 5.384903] RIP: 0010:usercopy_abort+0x6c/0x80[ 5.384903] Code: 1a 86 51 48 c7 c2 40 15 1a 86 41 52 48 c7 c7 c0 15 1a 86 48 0f 45 d6 48 c7 c6 80 15 1a 86 48 89 c1 49 0f 45 f3 e8 84 27 88 ff <0f> 0b 490[ 5.384903] RSP: 0018:ffffc900006f77a8 EFLAGS: 00010246[ 5.384903] RAX: 000000000000006f RBX: ffff88800f0ad2a8 RCX: 1ffffffff0f72e74[ 5.384903] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffffffff87b973a0[ 5.384903] RBP: 0000000000000010 R08: 0000000000000000 R09: fffffbfff0f72e74[ 5.384903] R10: 0000000000000003 R11: 79706f6372657375 R12: 0000000000000001[ 5.384903] R13: ffff88800f0ad2b8 R14: ffffea00003c2b40 R15: ffffea00003c2b00[ 5.384903] FS: 0000000011bc4380(0000) GS:ffff8880bf100000(0000) knlGS:0000000000000000[ 5.384903] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 5.384903] CR2: 000056aa3b8e5fe4 CR3: 000000000ea26004 CR4: 0000000000770ef0[ 5.384903] PKRU: 55555554[ 5.384903] Call Trace:[ 5.384903] [ 5.384903] __check_heap_object+0x9a/0xd0[ 5.384903] __check_object_size+0x46c/0x690[ 5.384903] put_cmsg+0x129/0x5e0[ 5.384903] sock_recv_errqueue+0x22f/0x380[ 5.384903] tls_sw_recvmsg+0x7ed/0x1960[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? schedule+0x6d/0x270[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5[ 5.384903] ? mutex_unlock+0x81/0xd0[ 5.384903] ? __pfx_mutex_unlock+0x10/0x10[ 5.384903] ? __pfx_tls_sw_recvmsg+0x10/0x10[ 5.384903] ? _raw_spin_lock_irqsave+0x8f/0xf0[ 5.384903] ? _raw_read_unlock_irqrestore+0x20/0x40[ 5.384903] ? srso_alias_return_thunk+0x5/0xfbef5The crash offset 296 corresponds to skb2->cb within skbuff_fclones: - sizeof(struct sk_buff) = 232 - offsetof(struct sk_buff, cb) = 40 - offset of skb2.cb in fclones = 232 + 40 = 272 - crash offset 296 = 272 + 24 (inside sock_exterr_skb.ee)This patch uses a local stack variable as a bounce buffer to avoid the hardened usercopy check failure.[1] https://elixir.bootlin.com/linux/v6.12.62/source/net/ipv4/tcp.c#L885[2] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5104[3] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5566[4] https://elixir.bootlin.com/linux/v6.12.62/source/net/core/skbuff.c#L5491[5] https://elixir.bootlin.com/linux/v6.12.62/source/mm/slub.c#L5719

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52612 Severity: Important CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: scomp - fix req->dst buffer overflowThe req->dst buffer size should be checked before copying from thescomp_scratch->dst to avoid req->dst buffer overflow problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50650 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix reference state management for synchronous callbacksCurrently, verifier verifies callback functions (sync and async) as ifthey will be executed once, (i.e. it explores execution state as if thefunction was being called once). The next insn to explore is set tostart of subprog and the exit from nested frame is handled usingcurframe > 0 and prepare_func_exit. In case of async callback it uses acustomized variant of push_stack simulating a kind of branch to set upcustom state and execution context for the async callback.While this approach is simple and works when callback really will beexecuted only once, it is unsafe for all of our current helpers whichare for_each style, i.e. they execute the callback multiple times.A callback releasing acquired references of the caller may do somultiple times, but currently verifier sees it as one call inside theframe, which then returns to caller. Hence, it thinks it released somereference that the cb e.g. got access through callback_ctx (registerfilled inside cb from spilled typed register on stack).Similarly, it may see that an acquire call is unpaired inside thecallback, so the caller will copy the reference state of callback andthen will have to release the register with new ref_obj_ids. But again,the callback may execute multiple times, but the verifier will onlyaccount for acquired references for a single symbolic execution of thecallback, which will cause leaks.Note that for async callback case, things are different. While currentlywe have bpf_timer_set_callback which only executes it once, even formultiple executions it would be safe, as reference state is NULL andcheck_reference_leak would force program to release state beforeBPF_EXIT. The state is also unaffected by analysis for the caller frame.Hence async callback is safe.Since we want the reference state to be accessible, e.g. for pointersloaded from stack through callback_ctx's PTR_TO_STACK, we still have tocopy caller's reference_state to callback's bpf_func_state, but weenforce that whatever references it adds to that reference_state hasbeen released before it hits BPF_EXIT. This requires introducing a newcallback_ref member in the reference state to distinguish between callervs callee references. Hence, check_reference_leak now errors out if itsees we are in callback_fn and we have not released callback_ref refs.Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2etc. we need to also distinguish between whether this particular refbelongs to this callback frame or parent, and only error for our own, sowe store state->frameno (which is always non-zero for callbacks).In short, callbacks can read parent reference_state, but cannot mutateit, to be able to use pointers acquired by the caller. They must onlyundo their changes (by releasing their own acquired_refs beforeBPF_EXIT) on top of caller reference_state before returning (at whichpoint the caller and callback state will match anyway, so no need tocopy it back to caller).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53586 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix multiple LUN_RESET handlingThis fixes a bug where an initiator thinks a LUN_RESET has cleaned uprunning commands when it hasn't. The bug was added in commit 51ec502a3266("target: Delete tmr from list before processing").The problem occurs when: 1. We have N I/O cmds running in the target layer spread over 2 sessions. 2. The initiator sends a LUN_RESET for each session. 3. session1's LUN_RESET loops over all the running commands from both sessions and moves them to its local drain_task_list. 4. session2's LUN_RESET does not see the LUN_RESET from session1 because the commit above has it remove itself. session2 also does not see any commands since the other reset moved them off the state lists. 5. sessions2's LUN_RESET will then complete with a successful response. 6. sessions2's inititor believes the running commands on its session are now cleaned up due to the successful response and cleans up the running commands from its side. It then restarts them. 7. The commands do eventually complete on the backend and the target starts to return aborted task statuses for them. The initiator will either throw a invalid ITT error or might accidentally lookup a new task if the ITT has been reallocated already.Fix the bug by reverting the patch, and serialize the execution ofLUN_RESETs and Preempt and Aborts.Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,because it turns out the original patch fixed a bug that was notmentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a secondLUN_RESET and wait on it. Then the second reset will runcore_tmr_drain_tmr_list and see the first reset and wait on it resulting ina deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36910 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Don't free decrypted memoryIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus device UIO driver could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the gpadlto decide whether to free the memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41038 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Prevent buffer overrun when processing V2 alg headersCheck that all fields of a V2 algorithm header fit into the availablefirmware data buffer.The wmfw V2 format introduced variable-length strings in the algorithmblock header. This means the overall header length is variable, and theposition of most fields varies depending on the length of the stringfields. Each field must be checked to ensure that it does not overflowthe firmware data buffer.As this ia bugfix patch, the fixes avoid making any significant change tothe existing code. This makes it easier to review and less likely tointroduce new bugs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47742 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware_loader: Block path traversalMost firmware names are hardcoded strings, or are constructed from fairlyconstrained format strings where the dynamic parts are just some hexnumbers or such.However, there are a couple codepaths in the kernel where firmware filenames contain string components that are passed through from a device orsemi-privileged userspace; the ones I could find (not counting interfacesthat require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from "ModelName", a string that was previously parsed out of some descriptor ("Vital Product Data") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, "nffw.partno"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like "netronome/nic_%s", and there shouldn't be any *folders* starting with "netronome/nic_". The previous case was different because there, the "%s" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.)Fix it by rejecting any firmware names containing ".." path components.For what it's worth, I went looking and haven't found any USB devicedrivers that use the firmware loader dangerously.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56566 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: Avoid list corruption when removing a slab from the full listBoot with slub_debug=UFPZ.If allocated object failed in alloc_consistency_checks, all objects ofthe slab will be marked as used, and then the slab will be removed fromthe partial list.When an object belonging to the slab got freed later, the remove_full()function is called. Because the slab is neither on the partial list noron the full list, it eventually lead to a list corruption (actually alist poison being detected).So we need to mark and isolate the slab page with metadata corruption,do not put it back in circulation.Because the debug caches avoid all the fastpaths, reusing the frozen bitto mark slab page with metadata corruption seems to be fine.[ 4277.385669] list_del corruption, ffffea00044b3e50->next is LIST_POISON1 (dead000000000100)[ 4277.387023] ------------[ cut here ]------------[ 4277.387880] kernel BUG at lib/list_debug.c:56![ 4277.388680] invalid opcode: 0000 [#1] PREEMPT SMP PTI[ 4277.389562] CPU: 5 PID: 90 Comm: kworker/5:1 Kdump: loaded Tainted: G OE 6.6.1-1 #1[ 4277.392113] Workqueue: xfs-inodegc/vda1 xfs_inodegc_worker [xfs][ 4277.393551] RIP: 0010:__list_del_entry_valid_or_report+0x7b/0xc0[ 4277.394518] Code: 48 91 82 e8 37 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 28 49 91 82 e8 26 f9 9a ff 0f 0b 48 89 fe 48 c7 c7 58 49 91[ 4277.397292] RSP: 0018:ffffc90000333b38 EFLAGS: 00010082[ 4277.398202] RAX: 000000000000004e RBX: ffffea00044b3e50 RCX: 0000000000000000[ 4277.399340] RDX: 0000000000000002 RSI: ffffffff828f8715 RDI: 00000000ffffffff[ 4277.400545] RBP: ffffea00044b3e40 R08: 0000000000000000 R09: ffffc900003339f0[ 4277.401710] R10: 0000000000000003 R11: ffffffff82d44088 R12: ffff888112cf9910[ 4277.402887] R13: 0000000000000001 R14: 0000000000000001 R15: ffff8881000424c0[ 4277.404049] FS: 0000000000000000(0000) GS:ffff88842fd40000(0000) knlGS:0000000000000000[ 4277.405357] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4277.406389] CR2: 00007f2ad0b24000 CR3: 0000000102a3a006 CR4: 00000000007706e0[ 4277.407589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4277.408780] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4277.410000] PKRU: 55555554[ 4277.410645] Call Trace:[ 4277.411234] [ 4277.411777] ? die+0x32/0x80[ 4277.412439] ? do_trap+0xd6/0x100[ 4277.413150] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.414158] ? do_error_trap+0x6a/0x90[ 4277.414948] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.415915] ? exc_invalid_op+0x4c/0x60[ 4277.416710] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.417675] ? asm_exc_invalid_op+0x16/0x20[ 4277.418482] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.419466] ? __list_del_entry_valid_or_report+0x7b/0xc0[ 4277.420410] free_to_partial_list+0x515/0x5e0[ 4277.421242] ? xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.422298] xfs_iext_remove+0x41a/0xa10 [xfs][ 4277.423316] ? xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.424383] xfs_bmap_del_extent_delay+0x4fe/0x7d0 [xfs][ 4277.425490] __xfs_bunmapi+0x50d/0x840 [xfs][ 4277.426445] xfs_itruncate_extents_flags+0x13a/0x490 [xfs][ 4277.427553] xfs_inactive_truncate+0xa3/0x120 [xfs][ 4277.428567] xfs_inactive+0x22d/0x290 [xfs][ 4277.429500] xfs_inodegc_worker+0xb4/0x1a0 [xfs][ 4277.430479] process_one_work+0x171/0x340[ 4277.431227] worker_thread+0x277/0x390[ 4277.431962] ? __pfx_worker_thread+0x10/0x10[ 4277.432752] kthread+0xf0/0x120[ 4277.433382] ? __pfx_kthread+0x10/0x10[ 4277.434134] ret_from_fork+0x2d/0x50[ 4277.434837] ? __pfx_kthread+0x10/0x10[ 4277.435566] ret_from_fork_asm+0x1b/0x30[ 4277.436280]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38702 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: fix potential buffer overflow in do_register_framebuffer()The current implementation may lead to buffer overflow when:1. Unregistration creates NULL gaps in registered_fb[]2. All array slots become occupied despite num_registered_fb < FB_MAX3. The registration loop exceeds array boundsAdd boundary check to prevent registered_fb[FB_MAX] access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40281 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: prevent possible shift-out-of-bounds in sctp_transport_update_rtosyzbot reported a possible shift-out-of-bounds [1]Blamed commit added rto_alpha_max and rto_beta_max set to 1000.It is unclear if some sctp users are setting very large rto_alphaand/or rto_beta.In order to prevent user regression, perform the test at run time.Also add READ_ONCE() annotations as sysctl values can change under us.[1]UBSAN: shift-out-of-bounds in net/sctp/transport.c:509:41shift exponent 64 is too large for 32-bit type 'unsigned int'CPU: 0 UID: 0 PID: 16704 Comm: syz.2.2320 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:233 [inline] __ubsan_handle_shift_out_of_bounds+0x27f/0x420 lib/ubsan.c:494 sctp_transport_update_rto.cold+0x1c/0x34b net/sctp/transport.c:509 sctp_check_transmitted+0x11c4/0x1c30 net/sctp/outqueue.c:1502 sctp_outq_sack+0x4ef/0x1b20 net/sctp/outqueue.c:1338 sctp_cmd_process_sack net/sctp/sm_sideeffect.c:840 [inline] sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1372 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-46802 Severity: Moderate CVSS3 score: 6.0

Description: For a short time they PTY is set to mode 666, allowing any user on the system to connect to the screen session.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
screen > 0-0 (version in image is 4.6.2-150000.5.8.1).

CVE-2025-61915 Severity: Moderate CVSS3 score: 6.0

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a user in the lpadmin group can use the cups web ui to change the config and insert a malicious line. Then the cupsd process which runs as root will parse the new config and cause an out-of-bound write. This issue has been patched in version 2.4.15.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.72.1).

CVE-2023-48795 Severity: Important CVSS3 score: 5.9

Description: The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-paramiko > 0-0 (version in image is 3.4.0-150400.13.10.4).

CVE-2020-25659 Severity: Moderate CVSS3 score: 5.9

Description: python-cryptography 3.2 is vulnerable to Bleichenbacher timing attacks in the RSA decryption API, via timed processing of valid PKCS#1 v1.5 ciphertext.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-cryptography > 0-0 (version in image is 3.3.2-150400.26.1).

CVE-2022-50483 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid buffer leaks on xdp_do_redirect() failureBefore enetc_clean_rx_ring_xdp() calls xdp_do_redirect(), each softwareBD in the RX ring between index orig_i and i can have one of 2 refcountvalues on its page.We are the owner of the current buffer that is being processed, so therefcount will be at least 1.If the current owner of the buffer at the diametrically opposed indexin the RX ring (i.o.w, the other half of this page) has not yet calledkfree(), this page's refcount could even be 2.enetc_page_reusable() in enetc_flip_rx_buff() tests for the pagerefcount against 1, and [ if it's 2 ] does not attempt to reuse it.But if enetc_flip_rx_buff() is put after the xdp_do_redirect() call,the page refcount can have one of 3 values. It can also be 0, if thereis no owner of the other page half, and xdp_do_redirect() for thisbuffer ran so far that it triggered a flush of the devmap/cpumap bulkqueue, and the consumers of those bulk queues also freed the buffer,all by the time xdp_do_redirect() returns the execution back to enetc.This is the reason why enetc_flip_rx_buff() is called beforexdp_do_redirect(), but there is a big flaw with that reasoning:enetc_flip_rx_buff() will set rx_swbd->page = NULL on both sides of theenetc_page_reusable() branch, and if xdp_do_redirect() returns an error,we call enetc_xdp_free(), which does not deal gracefully with that.In fact, what happens is quite special. The page refcounts start as 1.enetc_flip_rx_buff() figures they're reusable, transfers theserx_swbd->page pointers to a different rx_swbd in enetc_reuse_page(), andbumps the refcount to 2. When xdp_do_redirect() later returns an error,we call the no-op enetc_xdp_free(), but we still haven't lost thereference to that page. A copy of it is still at rx_ring->next_to_alloc,but that has refcount 2 (and there are no concurrent owners of it inflight, to drop the refcount). What really kills the system is whenwe'll flip the rx_swbd->page the second time around. With an updatedrefcount of 2, the page will not be reusable and we'll really leak it.Then enetc_new_page() will have to allocate more pages, which will theneventually leak again on further errors from xdp_do_redirect().The problem, summarized, is that we zeroize rx_swbd->page before we'recompletely done with it, and this makes it impossible for the error pathto do something with it.Since the packet is potentially multi-buffer and therefore therx_swbd->page is potentially an array, manual passing of the oldpointers between enetc_flip_rx_buff() and enetc_xdp_free() is a bitdifficult.For the sake of going with a simple solution, we accept the possibilityof racing with xdp_do_redirect(), and we move the flip procedure toexecute only on the redirect success path. By racing, I mean that thepage may be deemed as not reusable by enetc (having a refcount of 0),but there will be no leak in that case, either.Once we accept that, we have something better to do with buffers onXDP_REDIRECT failure. Since we haven't performed half-page flipping yet,we won't, either (and this way, we can avoid enetc_xdp_free()completely, which gives the entire page to the slab allocator).Instead, we'll call enetc_xdp_drop(), which will recycle this half ofthe buffer back to the RX ring.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50569 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Update ipcomp_scratches with NULL when freedCurrently if ipcomp_alloc_scratches() fails to allocate memoryipcomp_scratches holds obsolete address. So when we try to free thepercpu scratches using ipcomp_free_scratches() it tries to vfree nonexistent vm area. Described below:static void * __percpu *ipcomp_alloc_scratches(void){ ... scratches = alloc_percpu(void *); if (!scratches) return NULL;ipcomp_scratches does not know about this allocation failure.Therefore holding the old obsolete address. ...}So when we free,static void ipcomp_free_scratches(void){ ... scratches = ipcomp_scratches;Assigning obsolete address from ipcomp_scratches if (!scratches) return; for_each_possible_cpu(i) vfree(*per_cpu_ptr(scratches, i));Trying to free non existent page, causing warning: trying to vfreeexistent vm area. ...}Fix this breakage by updating ipcomp_scrtches with NULL when scratchesis freed

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-49082 Severity: Moderate CVSS3 score: 5.9

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation makes it possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling). This issue has been patched in version 3.9.0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2023-5981 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found that the response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from response times of ciphertexts with correct PKCS#1 v1.5 padding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2023-7008 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in systemd-resolved. This issue may allow systemd-resolved to accept records of DNSSEC-signed domains even when they have no signature, allowing man-in-the-middles (or the upstream DNS resolver) to manipulate records.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libsystemd0 > 0-0 (version in image is 249.17-150400.8.49.2).

CVE-2024-0553 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from the response times of ciphertexts with correct PKCS#1 v1.5 padding. This issue may allow a remote attacker to perform a timing side-channel attack in the RSA-PSK key exchange, potentially leading to the leakage of sensitive data. CVE-2024-0553 is designated as an incomplete resolution for CVE-2023-5981.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-0567 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability was found in GnuTLS, where a cockpit (which uses gnuTLS) rejects a certificate chain with distributed trust. This issue occurs when validating a certificate chain with cockpit-certificate-ensure. This flaw allows an unauthenticated, remote client or attacker to initiate a denial of service attack.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-11584 Severity: Moderate CVSS3 score: 5.9

Description: cloud-init through 25.1.2 includes the systemd socket unit cloud-init-hotplugd.socket with default SocketMode that grants 0666 permissions, making it world-writable. This is used for the "/run/cloud-init/hook-hotplug-cmd" FIFO. An unprivileged user could trigger hotplug-hook commands.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).

CVE-2024-47081 Severity: Moderate CVSS3 score: 5.9

Description: Requests is a HTTP library. Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. Users should upgrade to version 2.32.4 to receive a fix. For older versions of Requests, use of the .netrc file can be disabled with `trust_env=False` on one's Requests Session.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-requests > 0-0 (version in image is 2.25.1-150300.3.18.1).

CVE-2024-50602 Severity: Moderate CVSS3 score: 5.9

Description: An issue was discovered in libexpat before 2.6.4. There is a crash within the XML_ResumeParser function because XML_StopParser can stop/suspend an unstarted parser.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2024-56431 Severity: Moderate CVSS3 score: 5.9

Description: oc_huff_tree_unpack in huffdec.c in libtheora in Theora through 1.0 7180717 has an invalid negative left shift. NOTE: this is disputed by third parties because there is no evidence of a security impact, e.g., an application would not crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libmozjs-60 > 0-0 (version in image is 60.9.0-150200.6.3.1).

CVE-2024-56703 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix soft lockups in fib6_select_path under high next hop churnSoft lockups have been observed on a cluster of Linux-based edge routerslocated in a highly dynamic environment. Using the `bird` service, theserouters continuously update BGP-advertised routes due to frequentlychanging nexthop destinations, while also managing significant IPv6traffic. The lockups occur during the traversal of the multipathcircular linked-list in the `fib6_select_path` function, particularlywhile iterating through the siblings in the list. The issue typicallyarises when the nodes of the linked list are unexpectedly deletedconcurrently on a different core-indicated by their 'next' and'previous' elements pointing back to the node itself and their referencecount dropping to zero. This results in an infinite loop, leading to asoft lockup that triggers a system panic via the watchdog timer.Apply RCU primitives in the problematic code sections to resolve theissue. Where necessary, update the references to fib6_siblings toannotate or use the RCU APIs.Include a test script that reproduces the issue. The scriptperiodically updates the routing table while generating a heavy loadof outgoing IPv6 traffic through multiple iperf3 clients. Itconsistently induces infinite soft lockups within a couple of minutes.Kernel log: 0 [ffffbd13003e8d30] machine_kexec at ffffffff8ceaf3eb 1 [ffffbd13003e8d90] __crash_kexec at ffffffff8d0120e3 2 [ffffbd13003e8e58] panic at ffffffff8cef65d4 3 [ffffbd13003e8ed8] watchdog_timer_fn at ffffffff8d05cb03 4 [ffffbd13003e8f08] __hrtimer_run_queues at ffffffff8cfec62f 5 [ffffbd13003e8f70] hrtimer_interrupt at ffffffff8cfed756 6 [ffffbd13003e8fd0] __sysvec_apic_timer_interrupt at ffffffff8cea01af 7 [ffffbd13003e8ff0] sysvec_apic_timer_interrupt at ffffffff8df1b83d-- -- 8 [ffffbd13003d3708] asm_sysvec_apic_timer_interrupt at ffffffff8e000ecb [exception RIP: fib6_select_path+299] RIP: ffffffff8ddafe7b RSP: ffffbd13003d37b8 RFLAGS: 00000287 RAX: ffff975850b43600 RBX: ffff975850b40200 RCX: 0000000000000000 RDX: 000000003fffffff RSI: 0000000051d383e4 RDI: ffff975850b43618 RBP: ffffbd13003d3800 R8: 0000000000000000 R9: ffff975850b40200 R10: 0000000000000000 R11: 0000000000000000 R12: ffffbd13003d3830 R13: ffff975850b436a8 R14: ffff975850b43600 R15: 0000000000000007 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 9 [ffffbd13003d3808] ip6_pol_route at ffffffff8ddb030c10 [ffffbd13003d3888] ip6_pol_route_input at ffffffff8ddb068c11 [ffffbd13003d3898] fib6_rule_lookup at ffffffff8ddf02b512 [ffffbd13003d3928] ip6_route_input at ffffffff8ddb0f4713 [ffffbd13003d3a18] ip6_rcv_finish_core.constprop.0 at ffffffff8dd950d014 [ffffbd13003d3a30] ip6_list_rcv_finish.constprop.0 at ffffffff8dd9627415 [ffffbd13003d3a98] ip6_sublist_rcv at ffffffff8dd9647416 [ffffbd13003d3af8] ipv6_list_rcv at ffffffff8dd9661517 [ffffbd13003d3b60] __netif_receive_skb_list_core at ffffffff8dc16fec18 [ffffbd13003d3be0] netif_receive_skb_list_internal at ffffffff8dc176b319 [ffffbd13003d3c50] napi_gro_receive at ffffffff8dc565b920 [ffffbd13003d3c80] ice_receive_skb at ffffffffc087e4f5 [ice]21 [ffffbd13003d3c90] ice_clean_rx_irq at ffffffffc0881b80 [ice]22 [ffffbd13003d3d20] ice_napi_poll at ffffffffc088232f [ice]23 [ffffbd13003d3d80] __napi_poll at ffffffff8dc1800024 [ffffbd13003d3db8] net_rx_action at ffffffff8dc1858125 [ffffbd13003d3e40] __do_softirq at ffffffff8df352e926 [ffffbd13003d3eb0] run_ksoftirqd at ffffffff8ceffe4727 [ffffbd13003d3ec0] smpboot_thread_fn at ffffffff8cf36a3028 [ffffbd13003d3ee8] kthread at ffffffff8cf2b39f29 [ffffbd13003d3f28] ret_from_fork at ffffffff8ce5fa6430 [ffffbd13003d3f50] ret_from_fork_asm at ffffffff8ce03cbb

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56718 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: protect link down work from execute after lgr freedlink down work may be scheduled before lgr freed but executeafter lgr freed, which may result in crash. So it is need tohold a reference before shedule link down work, and put thereference after work executed or canceled.The relevant crash call stack as follows: list_del corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smc_link_down_work [smc] RIP: 0010:__list_del_entry_valid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsem_down_write_slowpath+0x17e/0x470 smc_link_down_work+0x3c/0x60 [smc] process_one_work+0x1ac/0x350 worker_thread+0x49/0x2f0 ? rescuer_thread+0x360/0x360 kthread+0x118/0x140 ? __kthread_bind_mask+0x60/0x60 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21959 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conncount: Fully initialize struct nf_conncount_tuple in insert_tree()Since commit b36e4523d4d5 ("netfilter: nf_conncount: fix garbagecollection confirm race"), `cpu` and `jiffies32` were introduced tothe struct nf_conncount_tuple.The commit made nf_conncount_add() initialize `conn->cpu` and`conn->jiffies32` when allocating the struct.In contrast, count_tree() was not changed to initialize them.By commit 34848d5c896e ("netfilter: nf_conncount: Split insert andtraversal"), count_tree() was split and the relevant allocationcode now resides in insert_tree().Initialize `conn->cpu` and `conn->jiffies32` in insert_tree().BUG: KMSAN: uninit-value in find_or_evict net/netfilter/nf_conncount.c:117 [inline]BUG: KMSAN: uninit-value in __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 find_or_evict net/netfilter/nf_conncount.c:117 [inline] __nf_conncount_add+0xd9c/0x2850 net/netfilter/nf_conncount.c:143 count_tree net/netfilter/nf_conncount.c:438 [inline] nf_conncount_count+0x82f/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ipv4/ip_input.c:669 __netif_receive_skb_list_ptype net/core/dev.c:5936 [inline] __netif_receive_skb_list_core+0x15c5/0x1670 net/core/dev.c:5983 __netif_receive_skb_list net/core/dev.c:6035 [inline] netif_receive_skb_list_internal+0x1085/0x1700 net/core/dev.c:6126 netif_receive_skb_list+0x5a/0x460 net/core/dev.c:6178 xdp_recv_frames net/bpf/test_run.c:280 [inline] xdp_test_run_batch net/bpf/test_run.c:361 [inline] bpf_test_run_xdp_live+0x2e86/0x3480 net/bpf/test_run.c:390 bpf_prog_test_run_xdp+0xf1d/0x1ae0 net/bpf/test_run.c:1316 bpf_prog_test_run+0x5e5/0xa30 kernel/bpf/syscall.c:4407 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5813 __do_sys_bpf kernel/bpf/syscall.c:5902 [inline] __se_sys_bpf kernel/bpf/syscall.c:5900 [inline] __ia32_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5900 ia32_sys_call+0x394d/0x4180 arch/x86/include/generated/asm/syscalls_32.h:358 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/common.c:387 do_fast_syscall_32+0x38/0x80 arch/x86/entry/common.c:412 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:450 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4121 [inline] slab_alloc_node mm/slub.c:4164 [inline] kmem_cache_alloc_noprof+0x915/0xe10 mm/slub.c:4171 insert_tree net/netfilter/nf_conncount.c:372 [inline] count_tree net/netfilter/nf_conncount.c:450 [inline] nf_conncount_count+0x1415/0x1e80 net/netfilter/nf_conncount.c:521 connlimit_mt+0x7f6/0xbd0 net/netfilter/xt_connlimit.c:72 __nft_match_eval net/netfilter/nft_compat.c:403 [inline] nft_match_eval+0x1a5/0x300 net/netfilter/nft_compat.c:433 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x426/0x2290 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x1a5/0x230 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_slow_list+0x24d/0x860 net/netfilter/core.c:663 NF_HOOK_LIST include/linux/netfilter.h:350 [inline] ip_sublist_rcv+0x17b7/0x17f0 net/ipv4/ip_input.c:633 ip_list_rcv+0x9ef/0xa40 net/ip---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22063 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:netlabel: Fix NULL pointer exception caused by CALIPSO on IPv4 socketsWhen calling netlbl_conn_setattr(), addr->sa_family is usedto determine the function behavior. If sk is an IPv4 socket,but the connect function is called with an IPv6 address,the function calipso_sock_setattr() is triggered.Inside this function, the following code is executed:sk_fullsock(__sk) ? inet_sk(__sk)->pinet6 : NULL;Since sk is an IPv4 socket, pinet6 is NULL, leading to anull pointer dereference.This patch fixes the issue by checking if inet6_sk(sk)returns a NULL pointer before accessing pinet6.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-3360 Severity: Moderate CVSS3 score: 5.9

Description: A flaw was found in GLib. An integer overflow and buffer under-read occur when parsing a long invalid ISO 8601 timestamp with the g_date_time_new_from_iso8601() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2025-3576 Severity: Moderate CVSS3 score: 5.9

Description: A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
krb5 > 0-0 (version in image is 1.19.2-150400.3.18.1).

CVE-2025-38035 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: don't restore null sk_state_changequeue->state_change is set as part of nvmet_tcp_set_queue_sock(), but ifthe TCP connection isn't established when nvmet_tcp_set_queue_sock() iscalled then queue->state_change isn't set and sock->sk->sk_state_changeisn't replaced.As such we don't need to restore sock->sk->sk_state_change ifqueue->state_change is NULL.This avoids NULL pointer dereferences such as this:[ 286.462026][ C0] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 286.462814][ C0] #PF: supervisor instruction fetch in kernel mode[ 286.463796][ C0] #PF: error_code(0x0010) - not-present page[ 286.464392][ C0] PGD 8000000140620067 P4D 8000000140620067 PUD 114201067 PMD 0[ 286.465086][ C0] Oops: Oops: 0010 [#1] SMP KASAN PTI[ 286.465559][ C0] CPU: 0 UID: 0 PID: 1628 Comm: nvme Not tainted 6.15.0-rc2+ #11 PREEMPT(voluntary)[ 286.466393][ C0] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[ 286.467147][ C0] RIP: 0010:0x0[ 286.467420][ C0] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 286.467977][ C0] RSP: 0018:ffff8883ae008580 EFLAGS: 00010246[ 286.468425][ C0] RAX: 0000000000000000 RBX: ffff88813fd34100 RCX: ffffffffa386cc43[ 286.469019][ C0] RDX: 1ffff11027fa68b6 RSI: 0000000000000008 RDI: ffff88813fd34100[ 286.469545][ C0] RBP: ffff88813fd34160 R08: 0000000000000000 R09: ffffed1027fa682c[ 286.470072][ C0] R10: ffff88813fd34167 R11: 0000000000000000 R12: ffff88813fd344c3[ 286.470585][ C0] R13: ffff88813fd34112 R14: ffff88813fd34aec R15: ffff888132cdd268[ 286.471070][ C0] FS: 00007fe3c04c7d80(0000) GS:ffff88840743f000(0000) knlGS:0000000000000000[ 286.471644][ C0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 286.472543][ C0] CR2: ffffffffffffffd6 CR3: 000000012daca000 CR4: 00000000000006f0[ 286.473500][ C0] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 286.474467][ C0] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400[ 286.475453][ C0] Call Trace:[ 286.476102][ C0] [ 286.476719][ C0] tcp_fin+0x2bb/0x440[ 286.477429][ C0] tcp_data_queue+0x190f/0x4e60[ 286.478174][ C0] ? __build_skb_around+0x234/0x330[ 286.478940][ C0] ? rcu_is_watching+0x11/0xb0[ 286.479659][ C0] ? __pfx_tcp_data_queue+0x10/0x10[ 286.480431][ C0] ? tcp_try_undo_loss+0x640/0x6c0[ 286.481196][ C0] ? seqcount_lockdep_reader_access.constprop.0+0x82/0x90[ 286.482046][ C0] ? kvm_clock_get_cycles+0x14/0x30[ 286.482769][ C0] ? ktime_get+0x66/0x150[ 286.483433][ C0] ? rcu_is_watching+0x11/0xb0[ 286.484146][ C0] tcp_rcv_established+0x6e4/0x2050[ 286.484857][ C0] ? rcu_is_watching+0x11/0xb0[ 286.485523][ C0] ? ipv4_dst_check+0x160/0x2b0[ 286.486203][ C0] ? __pfx_tcp_rcv_established+0x10/0x10[ 286.486917][ C0] ? lock_release+0x217/0x2c0[ 286.487595][ C0] tcp_v4_do_rcv+0x4d6/0x9b0[ 286.488279][ C0] tcp_v4_rcv+0x2af8/0x3e30[ 286.488904][ C0] ? raw_local_deliver+0x51b/0xad0[ 286.489551][ C0] ? rcu_is_watching+0x11/0xb0[ 286.490198][ C0] ? __pfx_tcp_v4_rcv+0x10/0x10[ 286.490813][ C0] ? __pfx_raw_local_deliver+0x10/0x10[ 286.491487][ C0] ? __pfx_nf_confirm+0x10/0x10 [nf_conntrack][ 286.492275][ C0] ? rcu_is_watching+0x11/0xb0[ 286.492900][ C0] ip_protocol_deliver_rcu+0x8f/0x370[ 286.493579][ C0] ip_local_deliver_finish+0x297/0x420[ 286.494268][ C0] ip_local_deliver+0x168/0x430[ 286.494867][ C0] ? __pfx_ip_local_deliver+0x10/0x10[ 286.495498][ C0] ? __pfx_ip_local_deliver_finish+0x10/0x10[ 286.496204][ C0] ? ip_rcv_finish_core+0x19a/0x1f20[ 286.496806][ C0] ? lock_release+0x217/0x2c0[ 286.497414][ C0] ip_rcv+0x455/0x6e0[ 286.497945][ C0] ? __pfx_ip_rcv+0x10/0x10[ ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39797 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Duplicate SPI HandlingThe issue originates when Strongswan initiates an XFRM_MSG_ALLOCSPINetlink message, which triggers the kernel function xfrm_alloc_spi().This function is expected to ensure uniqueness of the Security ParameterIndex (SPI) for inbound Security Associations (SAs). However, it canreturn success even when the requested SPI is already in use, leadingto duplicate SPIs assigned to multiple inbound SAs, differentiatedonly by their destination addresses.This behavior causes inconsistencies during SPI lookups for inbound packets.Since the lookup may return an arbitrary SA among those with the same SPI,packet processing can fail, resulting in packet drops.According to RFC 4301 section 4.4.2 , for inbound processing a unicast SAis uniquely identified by the SPI and optionally protocol.Reproducing the Issue Reliably:To consistently reproduce the problem, restrict the available SPI range incharon.conf : spi_min = 0x10000000 spi_max = 0x10000002This limits the system to only 2 usable SPI values.Next, create more than 2 Child SA. each using unique pair of src/dst address.As soon as the 3rd Child SA is initiated, it will be assigned a duplicateSPI, since the SPI pool is already exhausted.With a narrow SPI range, the issue is consistently reproducible.With a broader/default range, it becomes rare and unpredictable.Current implementation:xfrm_spi_hash() lookup function computes hash using daddr, proto, and family.So if two SAs have the same SPI but different destination addresses, thenthey will:a. Hash into different bucketsb. Be stored in different linked lists (byspi + h)c. Not be seen in the same hlist_for_each_entry_rcu() iteration.As a result, the lookup will result in NULL and kernel allows that Duplicate SPIProposed Change:xfrm_state_lookup_spi_proto() does a truly global search - across all states,regardless of hash bucket and matches SPI and proto.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-58436 Severity: Moderate CVSS3 score: 5.9

Description: OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. Prior to version 2.4.15, a client that connects to cupsd but sends slow messages, e.g. only one byte per second, delays cupsd as a whole, such that it becomes unusable by other clients. This issue has been patched in version 2.4.15.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
cups-config > 0-0 (version in image is 2.2.7-150000.3.72.1).

CVE-2025-68768 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:inet: frags: flush pending skbs in fqdir_pre_exit()We have been seeing occasional deadlocks on pernet_ops_rwsem sinceSeptember in NIPA. The stuck task was usually modprobe (often loadinga driver like ipvlan), trying to take the lock as a Writer.lockdep does not track readers for rwsems so the read wasn't obviousfrom the reports.On closer inspection the Reader holding the lock was conntrack loopingforever in nf_conntrack_cleanup_net_list(). Based on past experiencewith occasional NIPA crashes I looked thru the tests which run beforethe crash and noticed that the crash follows ip_defrag.sh. An immediatered flag. Scouring thru (de)fragmentation queues reveals skbs sittingaround, holding conntrack references.The problem is that since conntrack depends on nf_defrag_ipv6,nf_defrag_ipv6 will load first. Since nf_defrag_ipv6 loads first itsnetns exit hooks run _after_ conntrack's netns exit hook.Flush all fragment queue SKBs during fqdir_pre_exit() to releaseconntrack references before conntrack cleanup runs. Also flushthe queues in timer expiry handlers when they discover fqdir->deadis set, in case packet sneaks in while we're running the pre_exitflush.The commit under Fixes is not exactly the culprit, but I thinkpreviously the timer firing would eventually unblock the spinningconntrack.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68776 Severity: Moderate CVSS3 score: 5.9

Description: In the Linux kernel, the following vulnerability has been resolved:net/hsr: fix NULL pointer dereference in prp_get_untagged_frame()prp_get_untagged_frame() calls __pskb_copy() to create frame->skb_stdbut doesn't check if the allocation failed. If __pskb_copy() returnsNULL, skb_clone() is called with a NULL pointer, causing a crash:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 0 UID: 0 PID: 5625 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:skb_clone+0xd7/0x3a0 net/core/skbuff.c:2041Code: 03 42 80 3c 20 00 74 08 4c 89 f7 e8 23 29 05 f9 49 83 3e 00 0f 85 a0 01 00 00 e8 94 dd 9d f8 48 8d 6b 7e 49 89 ee 49 c1 ee 03 <43> 0f b6 04 26 84 c0 0f 85 d1 01 00 00 44 0f b6 7d 00 41 83 e7 0cRSP: 0018:ffffc9000d00f200 EFLAGS: 00010207RAX: ffffffff892235a1 RBX: 0000000000000000 RCX: ffff88803372a480RDX: 0000000000000000 RSI: 0000000000000820 RDI: 0000000000000000RBP: 000000000000007e R08: ffffffff8f7d0f77 R09: 1ffffffff1efa1eeR10: dffffc0000000000 R11: fffffbfff1efa1ef R12: dffffc0000000000R13: 0000000000000820 R14: 000000000000000f R15: ffff88805144cc00FS: 0000555557f6d500(0000) GS:ffff88808d72f000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000555581d35808 CR3: 000000005040e000 CR4: 0000000000352ef0Call Trace: hsr_forward_do net/hsr/hsr_forward.c:-1 [inline] hsr_forward_skb+0x1013/0x2860 net/hsr/hsr_forward.c:741 hsr_handle_frame+0x6ce/0xa70 net/hsr/hsr_slave.c:84 __netif_receive_skb_core+0x10b9/0x4380 net/core/dev.c:5966 __netif_receive_skb_one_core net/core/dev.c:6077 [inline] __netif_receive_skb+0x72/0x380 net/core/dev.c:6192 netif_receive_skb_internal net/core/dev.c:6278 [inline] netif_receive_skb+0x1cb/0x790 net/core/dev.c:6337 tun_rx_batched+0x1b9/0x730 drivers/net/tun.c:1485 tun_get_user+0x2b65/0x3e90 drivers/net/tun.c:1953 tun_chr_write_iter+0x113/0x200 drivers/net/tun.c:1999 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x5c9/0xb30 fs/read_write.c:686 ksys_write+0x145/0x250 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0449f8e1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 f9 92 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 4c 93 02 00 48RSP: 002b:00007ffd7ad94c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007f044a1e5fa0 RCX: 00007f0449f8e1ffRDX: 000000000000003e RSI: 0000200000000500 RDI: 00000000000000c8RBP: 00007ffd7ad94d20 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000003e R11: 0000000000000293 R12: 0000000000000001R13: 00007f044a1e5fa0 R14: 00007f044a1e5fa0 R15: 0000000000000003 Add a NULL check immediately after __pskb_copy() to handle allocationfailures gracefully.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68972 Severity: Moderate CVSS3 score: 5.9

Description: In GnuPG through 2.4.8, if a signed message has \f at the end of a plaintext line, an adversary can construct a modified message that places additional text after the signed material, such that signature verification of the modified message succeeds (although an "invalid armor" message is printed during verification). This is related to use of \f as a marker to denote truncation of a long plaintext line.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).

CVE-2022-49939 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF of ref->proc caused by race conditionA transaction of type BINDER_TYPE_WEAK_HANDLE can fail to increment thereference for a node. In this case, the target proc normally releasesthe failed reference upon close as expected. However, if the target isdying in parallel the call will race with binder_deferred_release(), sothe target could have released all of its references by now leaving thecleanup of the new failed reference unhandled.The transaction then ends and the target proc gets released making theref->proc now a dangling pointer. Later on, ref->node is closed and weattempt to take spin_lock(&ref->proc->inner_lock), which leads to theuse-after-free bug reported below. Let's fix this by cleaning up thefailed reference on the spot instead of relying on the target to do so. ================================================================== BUG: KASAN: use-after-free in _raw_spin_lock+0xa8/0x150 Write of size 4 at addr ffff5ca207094238 by task kworker/1:0/590 CPU: 1 PID: 590 Comm: kworker/1:0 Not tainted 5.19.0-rc8 #10 Hardware name: linux,dummy-virt (DT) Workqueue: events binder_deferred_func Call trace: dump_backtrace.part.0+0x1d0/0x1e0 show_stack+0x18/0x70 dump_stack_lvl+0x68/0x84 print_report+0x2e4/0x61c kasan_report+0xa4/0x110 kasan_check_range+0xfc/0x1a4 __kasan_check_write+0x3c/0x50 _raw_spin_lock+0xa8/0x150 binder_deferred_func+0x5e0/0x9b0 process_one_work+0x38c/0x5f0 worker_thread+0x9c/0x694 kthread+0x188/0x190 ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50497 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: fix shift-out-of-bounds in check_special_flagsUBSAN reported a shift-out-of-bounds warning: left shift of 1 by 31 places cannot be represented in type 'int' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8d/0xcf lib/dump_stack.c:106 ubsan_epilogue+0xa/0x44 lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds+0x1e7/0x208 lib/ubsan.c:322 check_special_flags fs/binfmt_misc.c:241 [inline] create_entry fs/binfmt_misc.c:456 [inline] bm_register_write+0x9d3/0xa20 fs/binfmt_misc.c:654 vfs_write+0x11e/0x580 fs/read_write.c:582 ksys_write+0xcf/0x120 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x34/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x4194e1Since the type of Node's flags is unsigned long, we should define thesemacros with same type too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50563 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix UAF in run_timer_softirq()When dm_resume() and dm_destroy() are concurrent, it willlead to UAF, as follows: BUG: KASAN: use-after-free in __run_timers+0x173/0x710 Write of size 8 at addr ffff88816d9490f0 by task swapper/0/0 Call Trace: dump_stack_lvl+0x73/0x9f print_report.cold+0x132/0xaa2 _raw_spin_lock_irqsave+0xcd/0x160 __run_timers+0x173/0x710 kasan_report+0xad/0x110 __run_timers+0x173/0x710 __asan_store8+0x9c/0x140 __run_timers+0x173/0x710 call_timer_fn+0x310/0x310 pvclock_clocksource_read+0xfa/0x250 kvm_clock_read+0x2c/0x70 kvm_clock_get_cycles+0xd/0x20 ktime_get+0x5c/0x110 lapic_next_event+0x38/0x50 clockevents_program_event+0xf1/0x1e0 run_timer_softirq+0x49/0x90 __do_softirq+0x16e/0x62c __irq_exit_rcu+0x1fa/0x270 irq_exit_rcu+0x12/0x20 sysvec_apic_timer_interrupt+0x8e/0xc0One of the concurrency UAF can be shown as below: use freedo_resume | __find_device_hash_cell | dm_get | atomic_inc(&md->holders) | | dm_destroy | __dm_destroy | if (!dm_suspended_md(md)) | atomic_read(&md->holders) | msleep(1) dm_resume | __dm_resume | dm_table_resume_targets | pool_resume | do_waker #add delay work | dm_put | atomic_dec(&md->holders) | | dm_table_destroy | pool_dtr | __pool_dec | __pool_destroy | destroy_workqueue | kfree(pool) # free pool time out__do_softirq run_timer_softirq # pool has already been freedThis can be easily reproduced using: 1. create thin-pool 2. dmsetup suspend pool 3. dmsetup resume pool 4. dmsetup remove_all # Concurrent with 3The root cause of this UAF bug is that dm_resume() adds timer afterdm_destroy() skips cancelling the timer because of suspend status.After timeout, it will call run_timer_softirq(), however pool hasalready been freed. The concurrency UAF bug will happen.Therefore, cancelling timer again in __pool_destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53034 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ntb_hw_switchtec: Fix shift-out-of-bounds in switchtec_ntb_mw_set_transThere is a kernel API ntb_mw_clear_trans() would pass 0 to both addr andsize. This would make xlate_pos negative.[ 23.734156] switchtec switchtec0: MW 0: part 0 addr 0x0000000000000000 size 0x0000000000000000[ 23.734158] ================================================================================[ 23.734172] UBSAN: shift-out-of-bounds in drivers/ntb/hw/mscc/ntb_hw_switchtec.c:293:7[ 23.734418] shift exponent -1 is negativeEnsuring xlate_pos is a positive or zero before BIT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53536 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:blk-crypto: make blk_crypto_evict_key() more robustIf blk_crypto_evict_key() sees that the key is still in-use (due to abug) or that ->keyslot_evict failed, it currently just returns whileleaving the key linked into the keyslot management structures.However, blk_crypto_evict_key() is only called in contexts such as inodeeviction where failure is not an option. So actually the callerproceeds with freeing the blk_crypto_key regardless of the return valueof blk_crypto_evict_key().These two assumptions don't match, and the result is that there can be ause-after-free in blk_crypto_reprogram_all_keys() after one of theseerrors occurs. (Note, these errors *shouldn't* happen; we're justtalking about what happens if they do anyway.)Fix this by making blk_crypto_evict_key() unlink the key from thekeyslot management structures even on failure.Also improve some comments.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53612 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Simplify platform device handlingCoretemp's platform driver is unconventional. All the real work is doneglobally by the initcall and CPU hotplug notifiers, while the "driver"effectively just wraps an allocation and the registration of the hwmoninterface in a long-winded round-trip through the driver core. The wholelogic of dynamically creating and destroying platform devices to bringthe interfaces up and down is error prone, since it assumesplatform_device_add() will synchronously bind the driver and set drvdatabefore it returns, thus results in a NULL dereference if drivers_autoprobeis turned off for the platform bus. Furthermore, the unusual approach ofdoing that from within a CPU hotplug notifier, already commented in thecode that it deadlocks suspend, also causes lockdep issues for otherdrivers or subsystems which may want to legitimately register a CPUhotplug notifier from a platform bus notifier.All of these issues can be solved by ripping this unusual behaviour outcompletely, simply tying the platform devices to the lifetime of themodule itself, and directly managing the hwmon interfaces from thehotplug notifiers. There is a slight user-visible change in that/sys/bus/platform/drivers/coretemp will no longer appear, and/sys/devices/platform/coretemp.n will remain present if package n ishotplugged off, but hwmon users should really only be looking for thepresence of the hwmon interfaces, whose behaviour remains unchanged.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53629 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix use after free in midcomms commitWhile working on processing dlm message in softirq context I experiencedthe following KASAN use-after-free warning:[ 151.760477] ==================================================================[ 151.761803] BUG: KASAN: use-after-free in dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.763414] Read of size 4 at addr ffff88811a980c60 by task lock_torture/1347[ 151.765284] CPU: 7 PID: 1347 Comm: lock_torture Not tainted 6.1.0-rc4+ #2828[ 151.766778] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-3.module+el8.7.0+16134+e5908aa2 04/01/2014[ 151.768726] Call Trace:[ 151.769277] [ 151.769748] dump_stack_lvl+0x5b/0x86[ 151.770556] print_report+0x180/0x4c8[ 151.771378] ? kasan_complete_mode_report_info+0x7c/0x1e0[ 151.772241] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.773069] kasan_report+0x93/0x1a0[ 151.773668] ? dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.774514] __asan_load4+0x7e/0xa0[ 151.775089] dlm_midcomms_commit_mhandle+0x19d/0x4b0[ 151.775890] ? create_message.isra.29.constprop.64+0x57/0xc0[ 151.776770] send_common+0x19f/0x1b0[ 151.777342] ? remove_from_waiters+0x60/0x60[ 151.778017] ? lock_downgrade+0x410/0x410[ 151.778648] ? __this_cpu_preempt_check+0x13/0x20[ 151.779421] ? rcu_lockdep_current_cpu_online+0x88/0xc0[ 151.780292] _convert_lock+0x46/0x150[ 151.780893] convert_lock+0x7b/0xc0[ 151.781459] dlm_lock+0x3ac/0x580[ 151.781993] ? 0xffffffffc0540000[ 151.782522] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.783379] ? dlm_scan_rsbs+0xa70/0xa70[ 151.784003] ? preempt_count_sub+0xd6/0x130[ 151.784661] ? is_module_address+0x47/0x70[ 151.785309] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.786166] ? 0xffffffffc0540000[ 151.786693] ? lockdep_init_map_type+0xc3/0x360[ 151.787414] ? 0xffffffffc0540000[ 151.787947] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.789004] ? torture_stop+0x120/0x120 [dlm_locktorture][ 151.789858] ? 0xffffffffc0540000[ 151.790392] ? lock_torture_cleanup+0x20/0x20 [dlm_locktorture][ 151.791347] ? delay_tsc+0x94/0xc0[ 151.791898] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.792735] ? torture_start+0x30/0x30 [dlm_locktorture][ 151.793606] lock_torture+0x177/0x270 [dlm_locktorture][ 151.794448] ? torture_dlm_lock_sync.isra.3+0x150/0x150 [dlm_locktorture][ 151.795539] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.796476] ? do_raw_spin_lock+0x11e/0x1e0[ 151.797152] ? mark_held_locks+0x34/0xb0[ 151.797784] ? _raw_spin_unlock_irqrestore+0x30/0x70[ 151.798581] ? __kthread_parkme+0x79/0x110[ 151.799246] ? trace_preempt_on+0x2a/0xf0[ 151.799902] ? __kthread_parkme+0x79/0x110[ 151.800579] ? preempt_count_sub+0xd6/0x130[ 151.801271] ? __kasan_check_read+0x11/0x20[ 151.801963] ? __kthread_parkme+0xec/0x110[ 151.802630] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 151.803569] kthread+0x192/0x1d0[ 151.804104] ? kthread_complete_and_exit+0x30/0x30[ 151.804881] ret_from_fork+0x1f/0x30[ 151.805480] [ 151.806111] Allocated by task 1347:[ 151.806681] kasan_save_stack+0x26/0x50[ 151.807308] kasan_set_track+0x25/0x30[ 151.807920] kasan_save_alloc_info+0x1e/0x30[ 151.808609] __kasan_slab_alloc+0x63/0x80[ 151.809263] kmem_cache_alloc+0x1ad/0x830[ 151.809916] dlm_allocate_mhandle+0x17/0x20[ 151.810590] dlm_midcomms_get_mhandle+0x96/0x260[ 151.811344] _create_message+0x95/0x180[ 151.811994] create_message.isra.29.constprop.64+0x57/0xc0[ 151.812880] send_common+0x129/0x1b0[ 151.813467] _convert_lock+0x46/0x150[ 151.814074] convert_lock+0x7b/0xc0[ 151.814648] dlm_lock+0x3ac/0x580[ 151.815199] torture_dlm_lock_sync.isra.3+0xe9/0x150 [dlm_locktorture][ 151.816258] torture_ex_iter+0xc3/0xea [dlm_locktorture][ 151.817129] lock_t---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53694 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: ftrace: Fixup panic by disabling preemptionIn RISCV, we must use an AUIPC + JALR pair to encode an immediate,forming a jump that jumps to an address over 4K. This may cause errorsif we want to enable kernel preemption and remove dependency frompatching code with stop_machine(). For example, if a task was switchedout on auipc. And, if we changed the ftrace function before it wasswitched back, then it would jump to an address that has updated 11:0bits mixing with previous XLEN:12 part.p: patched area performed by dynamic ftraceftrace_prologue:p| REG_S ra, -SZREG(sp)p| auipc ra, 0x? ------------> preempted ... change ftrace function ...p| jalr -?(ra) <------------- switched backp| REG_L ra, -SZREG(sp)func: xxx ret

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54176 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: stricter state check in mptcp_workerAs reported by Christoph, the mptcp protocol can run theworker when the relevant msk socket is in an unexpected state:connect()// incoming reset + fastclose// the mptcp worker is scheduledmptcp_disconnect()// msk is now CLOSEDlisten()mptcp_worker()Leading to the following splat:divide error: 0000 [#1] PREEMPT SMPCPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014Workqueue: events mptcp_workerRIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018RSP: 0018:ffffc900000b3c98 EFLAGS: 00010293RAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004RBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000R10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_select_window net/ipv4/tcp_output.c:262 [inline] __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345 tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline] tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459 mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline] mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705 process_one_work+0x3bd/0x950 kernel/workqueue.c:2390 worker_thread+0x5b/0x610 kernel/workqueue.c:2537 kthread+0x138/0x170 kernel/kthread.c:376 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 This change addresses the issue explicitly checking for bad statesbefore running the mptcp worker.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54207 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:HID: uclogic: Correct devm device reference for hidinput input_dev nameReference the HID device rather than the input device for the devmallocation of the input_dev name. Referencing the input_dev would lead to ause-after-free when the input_dev was unregistered and subsequently fires auevent that depends on the name. At the point of firing the uevent, thename would be freed by devres management.Use devm_kasprintf to simplify the logic for allocating memory andformatting the input_dev name string.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54283 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Address KCSAN report on bpf_lru_listKCSAN reported a data-race when accessing node->ref.Although node->ref does not have to be accurate,take this chance to use a more common READ_ONCE() and WRITE_ONCE()pattern instead of data_race().There is an existing bpf_lru_node_is_ref() and bpf_lru_node_set_ref().This patch also adds bpf_lru_node_clear_ref() to do theWRITE_ONCE(node->ref, 0) also.==================================================================BUG: KCSAN: data-race in __bpf_lru_list_rotate / __htab_lru_percpu_map_update_elemwrite to 0xffff888137038deb of 1 bytes by task 11240 on cpu 1:__bpf_lru_node_move kernel/bpf/bpf_lru_list.c:113 [inline]__bpf_lru_list_rotate_active kernel/bpf/bpf_lru_list.c:149 [inline]__bpf_lru_list_rotate+0x1bf/0x750 kernel/bpf/bpf_lru_list.c:240bpf_lru_list_pop_free_to_local kernel/bpf/bpf_lru_list.c:329 [inline]bpf_common_lru_pop_free kernel/bpf/bpf_lru_list.c:447 [inline]bpf_lru_pop_free+0x638/0xe20 kernel/bpf/bpf_lru_list.c:499prealloc_lru_pop kernel/bpf/hashtab.c:290 [inline]__htab_lru_percpu_map_update_elem+0xe7/0x820 kernel/bpf/hashtab.c:1316bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888137038deb of 1 bytes by task 11241 on cpu 0:bpf_lru_node_set_ref kernel/bpf/bpf_lru_list.h:70 [inline]__htab_lru_percpu_map_update_elem+0x2f1/0x820 kernel/bpf/hashtab.c:1332bpf_percpu_hash_update+0x5e/0x90 kernel/bpf/hashtab.c:2313bpf_map_update_value+0x2a9/0x370 kernel/bpf/syscall.c:200generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1687bpf_map_do_batch+0x2d9/0x3d0 kernel/bpf/syscall.c:4534__sys_bpf+0x338/0x810__do_sys_bpf kernel/bpf/syscall.c:5096 [inline]__se_sys_bpf kernel/bpf/syscall.c:5094 [inline]__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5094do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 11241 Comm: syz-executor.3 Not tainted 6.3.0-rc7-syzkaller-00136-g6a66fdd29ea1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll: BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10: net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822) read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2: netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393) netpoll_send_udp (net/core/netpoll.c:?) value changed: 0x0000000a -> 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi->poll_ownernon atomically. The ->poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46675 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: Prevent USB core invalid event buffer address accessThis commit addresses an issue where the USB core could access aninvalid event buffer address during runtime suspend, potentially causingSMMU faults and other memory issues in Exynos platforms. The problemarises from the following sequence. 1. In dwc3_gadget_suspend, there is a chance of a timeout when moving the USB core to the halt state after clearing the run/stop bit by software. 2. In dwc3_core_exit, the event buffer is cleared regardless of the USB core's status, which may lead to an SMMU faults and other memory issues. if the USB core tries to access the event buffer address.To prevent this hardware quirk on Exynos platforms, this commit ensuresthat the event buffer address is not cleared by software when the USBcore is active during runtime suspend by checking its status beforeclearing the buffer address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53680 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix UB due to uninitialized stack access in ip_vs_protocol_init()Under certain kernel configurations when building with Clang/LLVM, thecompiler does not generate a return or jump as the terminatorinstruction for ip_vs_protocol_init(), triggering the following objtoolwarning during build time: vmlinux.o: warning: objtool: ip_vs_protocol_init() falls through to next function __initstub__kmod_ip_vs_rr__935_123_ip_vs_rr_init6()At runtime, this either causes an oops when trying to load the ipvsmodule or a boot-time panic if ipvs is built-in. This same issue hasbeen reported by the Intel kernel test robot previously.Digging deeper into both LLVM and the kernel code reveals this to be aundefined behavior problem. ip_vs_protocol_init() uses a on-stack bufferof 64 chars to store the registered protocol names and leaves ituninitialized after definition. The function calls strnlen() whenconcatenating protocol names into the buffer. With CONFIG_FORTIFY_SOURCEstrnlen() performs an extra step to check whether the last byte of theinput char buffer is a null character (commit 3009f891bb9f ("fortify:Allow strlen() and strnlen() to pass compile-time known lengths")).This, together with possibly other configurations, cause the followingIR to be generated: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #5 section ".init.text" align 16 !kcfi_type !29 { %1 = alloca [64 x i8], align 16 ... 14: ; preds = %11 %15 = getelementptr inbounds i8, ptr %1, i64 63 %16 = load i8, ptr %15, align 1 %17 = tail call i1 @llvm.is.constant.i8(i8 %16) %18 = icmp eq i8 %16, 0 %19 = select i1 %17, i1 %18, i1 false br i1 %19, label %20, label %23 20: ; preds = %14 %21 = call i64 @strlen(ptr noundef nonnull dereferenceable(1) %1) #23 ... 23: ; preds = %14, %11, %20 %24 = call i64 @strnlen(ptr noundef nonnull dereferenceable(1) %1, i64 noundef 64) #24 ... }The above code calculates the address of the last char in the buffer(value %15) and then loads from it (value %16). Because the buffer isnever initialized, the LLVM GVN pass marks value %16 as undefined: %13 = getelementptr inbounds i8, ptr %1, i64 63 br i1 undef, label %14, label %17This gives later passes (SCCP, in particular) more DCE opportunities bypropagating the undef value further, and eventually removes everythingafter the load on the uninitialized stack location: define hidden i32 @ip_vs_protocol_init() local_unnamed_addr #0 section ".init.text" align 16 !kcfi_type !11 { %1 = alloca [64 x i8], align 16 ... 12: ; preds = %11 %13 = getelementptr inbounds i8, ptr %1, i64 63 unreachable }In this way, the generated native code will just fall through to thenext function, as LLVM does not generate any code for the unreachable IRinstruction and leaves the function without a terminator.Zero the on-stack buffer to avoid this possible UB.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37903 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free in hdcpThe HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connectorobjects without incrementing the kref reference counts. When using aUSB-C dock, and the dock is unplugged, the correspondingamdgpu_dm_connector objects are freed, creating dangling pointers in theHDCP code. When the dock is plugged back, the dangling pointers aredereferenced, resulting in a slab-use-after-free:[ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10[ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233[ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024[ 66.776186] Workqueue: events event_property_validate [amdgpu][ 66.776494] Call Trace:[ 66.776496] [ 66.776497] dump_stack_lvl+0x70/0xa0[ 66.776504] print_report+0x175/0x555[ 66.776507] ? __virt_addr_valid+0x243/0x450[ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0[ 66.776515] kasan_report+0xeb/0x1c0[ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777121] __asan_report_load4_noabort+0x14/0x20[ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu][ 66.777342] ? __lock_acquire+0x6b40/0x6b40[ 66.777347] ? enable_assr+0x250/0x250 [amdgpu][ 66.777571] process_one_work+0x86b/0x1510[ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0[ 66.777578] ? assign_work+0x16b/0x280[ 66.777580] ? lock_is_held_type+0xa3/0x130[ 66.777583] worker_thread+0x5c0/0xfa0[ 66.777587] ? process_one_work+0x1510/0x1510[ 66.777588] kthread+0x3a2/0x840[ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777594] ? trace_hardirqs_on+0x4f/0x60[ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60[ 66.777599] ? calculate_sigpending+0x77/0xa0[ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777605] ret_from_fork+0x40/0x90[ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0[ 66.777609] ret_from_fork_asm+0x11/0x20[ 66.777614] [ 66.777643] Allocated by task 10:[ 66.777646] kasan_save_stack+0x39/0x60[ 66.777649] kasan_save_track+0x14/0x40[ 66.777652] kasan_save_alloc_info+0x37/0x50[ 66.777655] __kasan_kmalloc+0xbb/0xc0[ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0[ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu][ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper][ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper][ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper][ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper][ 66.777917] process_one_work+0x86b/0x1510[ 66.777919] worker_thread+0x5c0/0xfa0[ 66.777922] kthread+0x3a2/0x840[ 66.777925] ret_from_fork+0x40/0x90[ 66.777927] ret_from_fork_asm+0x11/0x20[ 66.777932] Freed by task 1713:[ 66.777935] kasan_save_stack+0x39/0x60[ 66.777938] kasan_save_track+0x14/0x40[ 66.777940] kasan_save_free_info+0x3b/0x60[ 66.777944] __kasan_slab_free+0x52/0x70[ 66.777946] kfree+0x13f/0x4b0[ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu][ 66.778179] drm_connector_free+0x7d/0xb0[ 66.778184] drm_mode_object_put.part.0+0xee/0x160[ 66.778188] drm_mode_object_put+0x37/0x50[ 66.778191] drm_atomic_state_default_clear+0x220/0xd60[ 66.778194] __drm_atomic_state_free+0x16e/0x2a0[ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0[ 66.778200] drm_ioctl_kernel+0x17a/0x310[ 66.778203] drm_ioctl+0x584/0xd10[ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu][ 66.778375] __x64_sys_ioctl+0x139/0x1a0[ 66.778378] x64_sys_call+0xee7/0xfb0[ 66.778381] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Add missing lockingRecent kernels complain about a missing lock in k3-udma.c when the lockvalidator is enabled:[ 4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238[ 4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28[ 4.144867] Hardware name: pp-v12 (DT)[ 4.148648] Workqueue: events udma_check_tx_completion[ 4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 4.160834] pc : udma_start.isra.0+0x34/0x238[ 4.165227] lr : udma_start.isra.0+0x30/0x238[ 4.169618] sp : ffffffc083cabcf0[ 4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005[ 4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000[ 4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670[ 4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030[ 4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048[ 4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001[ 4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68[ 4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8[ 4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000[ 4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000[ 4.244986] Call trace:[ 4.247463] udma_start.isra.0+0x34/0x238[ 4.251509] udma_check_tx_completion+0xd0/0xdc[ 4.256076] process_one_work+0x244/0x3fc[ 4.260129] process_scheduled_works+0x6c/0x74[ 4.264610] worker_thread+0x150/0x1dc[ 4.268398] kthread+0xd8/0xe8[ 4.271492] ret_from_fork+0x10/0x20[ 4.275107] irq event stamp: 220[ 4.278363] hardirqs last enabled at (219): [] _raw_spin_unlock_irq+0x38/0x50[ 4.287183] hardirqs last disabled at (220): [] el1_dbg+0x24/0x50[ 4.294879] softirqs last enabled at (182): [] handle_softirqs+0x1c0/0x3cc[ 4.303437] softirqs last disabled at (177): [] __do_softirq+0x1c/0x28[ 4.311559] ---[ end trace 0000000000000000 ]---This commit adds the missing locking.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38062 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookieThe IOMMU translation for MSI message addresses has been a 2-step process,separated in time: 1) iommu_dma_prepare_msi(): A cookie pointer containing the IOVA address is stored in the MSI descriptor when an MSI interrupt is allocated. 2) iommu_dma_compose_msi_msg(): this cookie pointer is used to compute a translated message address.This has an inherent lifetime problem for the pointer stored in the cookiethat must remain valid between the two steps. However, there is no lockingat the irq layer that helps protect the lifetime. Today, this works underthe assumption that the iommu domain is not changed while MSI interruptsbeing programmed. This is true for normal DMA API users within the kernel,as the iommu domain is attached before the driver is probed and cannot bechanged while a driver is attached.Classic VFIO type1 also prevented changing the iommu domain while VFIO wasrunning as it does not support changing the "container" after starting up.However, iommufd has improved this so that the iommu domain can be changedduring VFIO operation. This potentially allows userspace to directly raceVFIO_DEVICE_ATTACH_IOMMUFD_PT (which calls iommu_attach_group()) andVFIO_DEVICE_SET_IRQS (which calls into iommu_dma_compose_msi_msg()).This potentially causes both the cookie pointer and the unlocked call toiommu_get_domain_for_dev() on the MSI translation path to become UAFs.Fix the MSI cookie UAF by removing the cookie pointer. The translated IOVAaddress is already known during iommu_dma_prepare_msi() and cannot change.Thus, it can simply be stored as an integer in the MSI descriptor.The other UAF related to iommu_get_domain_for_dev() will be addressed inpatch "iommu: Make iommu_dma_prepare_msi() into a generic operation" byusing the IOMMU group mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38117 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Protect mgmt_pending list with its own lockThis uses a mutex to protect from concurrent access of mgmt_pendinglist which can cause crashes like:==================================================================BUG: KASAN: slab-use-after-free in hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91Read of size 2 at addr ffff0000c48885b2 by task syz.4.334/7318CPU: 0 UID: 0 PID: 7318 Comm: syz.4.334 Not tainted 6.15.0-rc7-syzkaller-g187899f4124a #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_address_description+0xa8/0x254 mm/kasan/report.c:408 print_report+0x68/0x84 mm/kasan/report.c:521 kasan_report+0xb0/0x110 mm/kasan/report.c:634 __asan_report_load2_noabort+0x20/0x2c mm/kasan/report_generic.c:379 hci_sock_get_channel+0x60/0x68 net/bluetooth/hci_sock.c:91 mgmt_pending_find+0x7c/0x140 net/bluetooth/mgmt_util.c:223 pending_find net/bluetooth/mgmt.c:947 [inline] remove_adv_monitor+0x44/0x1a4 net/bluetooth/mgmt.c:5445 hci_mgmt_cmd+0x780/0xc00 net/bluetooth/hci_sock.c:1712 hci_sock_sendmsg+0x544/0xbb0 net/bluetooth/hci_sock.c:1832 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] sock_write_iter+0x25c/0x378 net/socket.c:1131 new_sync_write fs/read_write.c:591 [inline] vfs_write+0x62c/0x97c fs/read_write.c:684 ksys_write+0x120/0x210 fs/read_write.c:736 __do_sys_write fs/read_write.c:747 [inline] __se_sys_write fs/read_write.c:744 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:744 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 7037: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x54 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x9c/0xb4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4327 [inline] __kmalloc_noprof+0x2fc/0x4c8 mm/slub.c:4339 kmalloc_noprof include/linux/slab.h:909 [inline] sk_prot_alloc+0xc4/0x1f0 net/core/sock.c:2198 sk_alloc+0x44/0x3ac net/core/sock.c:2254 bt_sock_alloc+0x4c/0x300 net/bluetooth/af_bluetooth.c:148 hci_sock_create+0xa8/0x194 net/bluetooth/hci_sock.c:2202 bt_sock_create+0x14c/0x24c net/bluetooth/af_bluetooth.c:132 __sock_create+0x43c/0x91c net/socket.c:1541 sock_create net/socket.c:1599 [inline] __sys_socket_create net/socket.c:1636 [inline] __sys_socket+0xd4/0x1c0 net/socket.c:1683 __do_sys_socket net/socket.c:1697 [inline] __se_sys_socket net/socket.c:1695 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1695 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Freed by task 6607: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_free_info+0x58/0x70 mm/kasan/generic.c:576 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x68/0x88 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38230 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: validate AG parameters in dbMount() to prevent crashesValidate db_agheight, db_agwidth, and db_agstart in dbMount to catchcorrupted metadata early and avoid undefined behavior in dbAllocAG.Limits are derived from L2LPERCTL, LPERCTL/MAXAG, and CTLTREESIZE:- agheight: 0 to L2LPERCTL/2 (0 to 5) ensures shift (L2LPERCTL - 2*agheight) >= 0.- agwidth: 1 to min(LPERCTL/MAXAG, 2^(L2LPERCTL - 2*agheight)) ensures agperlev >= 1. - Ranges: 1-8 (agheight 0-3), 1-4 (agheight 4), 1 (agheight 5). - LPERCTL/MAXAG = 1024/128 = 8 limits leaves per AG; 2^(10 - 2*agheight) prevents division to 0.- agstart: 0 to CTLTREESIZE-1 - agwidth*(MAXAG-1) keeps ti within stree (size 1365). - Ranges: 0-1237 (agwidth 1), 0-348 (agwidth 8).UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:1400:9shift exponent -335544310 is negativeCPU: 0 UID: 0 PID: 5822 Comm: syz-executor130 Not tainted 6.14.0-rc5-syzkaller #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 dbAllocAG+0x1087/0x10b0 fs/jfs/jfs_dmap.c:1400 dbDiscardAG+0x352/0xa20 fs/jfs/jfs_dmap.c:1613 jfs_ioc_trim+0x45a/0x6b0 fs/jfs/jfs_discard.c:105 jfs_ioctl+0x2cd/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFound by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38415 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check return result of sb_min_blocksizeSyzkaller reports an "UBSAN: shift-out-of-bounds in squashfs_bio_read" bug.Syzkaller forks multiple processes which after mounting the Squashfsfilesystem, issues an ioctl("/dev/loop0", LOOP_SET_BLOCK_SIZE, 0x8000). Now if this ioctl occurs at the same time another process is in theprocess of mounting a Squashfs filesystem on /dev/loop0, the failureoccurs. When this happens the following code in squashfs_fill_super()fails.----msblk->devblksize = sb_min_blocksize(sb, SQUASHFS_DEVBLK_SIZE);msblk->devblksize_log2 = ffz(~msblk->devblksize);----sb_min_blocksize() returns 0, which means msblk->devblksize is set to 0.As a result, ffz(~msblk->devblksize) returns 64, and msblk->devblksize_log2is set to 64.This subsequently causes theUBSAN: shift-out-of-bounds in fs/squashfs/block.c:195:36shift exponent 64 is too large for 64-bit type 'u64' (aka'unsigned long long')This commit adds a check for a 0 return by sb_min_blocksize().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38416 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: uart: Set tty->disc_data only in success pathSetting tty->disc_data before opening the NCI device means we need toclean it up on error paths. This also opens some short window if devicestarts sending data, even before NCIUARTSETDRIVER IOCTL succeeded(broken hardware?). Close the window by exposing tty->disc_data only onthe success path, when opening of the NCI device and try_module_get()succeeds.The code differs in error path in one aspect: tty->disc_data won't beever assigned thus NULL-ified. This however should not be relevantdifference, because of "tty->disc_data=NULL" in nci_uart_tty_open().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38464 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Fix use-after-free in tipc_conn_close().syzbot reported a null-ptr-deref in tipc_conn_close() during netnsdismantle. [0]tipc_topsrv_stop() iterates tipc_net(net)->topsrv->conn_idr and callstipc_conn_close() for each tipc_conn.The problem is that tipc_conn_close() is called after releasing theIDR lock.At the same time, there might be tipc_conn_recv_work() running and itcould call tipc_conn_close() for the same tipc_conn and release itslast ->kref.Once we release the IDR lock in tipc_topsrv_stop(), there is noguarantee that the tipc_conn is alive.Let's hold the ref before releasing the lock and put the ref aftertipc_conn_close() in tipc_topsrv_stop().[0]:BUG: KASAN: use-after-free in tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165Read of size 8 at addr ffff888099305a08 by task kworker/u4:3/435CPU: 0 PID: 435 Comm: kworker/u4:3 Not tainted 4.19.204-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x1fc/0x2ef lib/dump_stack.c:118 print_address_description.cold+0x54/0x219 mm/kasan/report.c:256 kasan_report_error.cold+0x8a/0x1b9 mm/kasan/report.c:354 kasan_report mm/kasan/report.c:412 [inline] __asan_report_load8_noabort+0x88/0x90 mm/kasan/report.c:433 tipc_conn_close+0x122/0x140 net/tipc/topsrv.c:165 tipc_topsrv_stop net/tipc/topsrv.c:701 [inline] tipc_topsrv_exit_net+0x27b/0x5c0 net/tipc/topsrv.c:722 ops_exit_list+0xa5/0x150 net/core/net_namespace.c:153 cleanup_net+0x3b4/0x8b0 net/core/net_namespace.c:553 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Allocated by task 23: kmem_cache_alloc_trace+0x12f/0x380 mm/slab.c:3625 kmalloc include/linux/slab.h:515 [inline] kzalloc include/linux/slab.h:709 [inline] tipc_conn_alloc+0x43/0x4f0 net/tipc/topsrv.c:192 tipc_topsrv_accept+0x1b5/0x280 net/tipc/topsrv.c:470 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415Freed by task 23: __cache_free mm/slab.c:3503 [inline] kfree+0xcc/0x210 mm/slab.c:3822 tipc_conn_kref_release net/tipc/topsrv.c:150 [inline] kref_put include/linux/kref.h:70 [inline] conn_put+0x2cd/0x3a0 net/tipc/topsrv.c:155 process_one_work+0x864/0x1570 kernel/workqueue.c:2153 worker_thread+0x64c/0x1130 kernel/workqueue.c:2296 kthread+0x33f/0x460 kernel/kthread.c:259 ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:415The buggy address belongs to the object at ffff888099305a00 which belongs to the cache kmalloc-512 of size 512The buggy address is located 8 bytes inside of 512-byte region [ffff888099305a00, ffff888099305c00)The buggy address belongs to the page:page:ffffea000264c140 count:1 mapcount:0 mapping:ffff88813bff0940 index:0x0flags: 0xfff00000000100(slab)raw: 00fff00000000100 ffffea00028b6b88 ffffea0002cd2b08 ffff88813bff0940raw: 0000000000000000 ffff888099305000 0000000100000006 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffff888099305900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305980: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc>ffff888099305a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888099305a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff888099305b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38584 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:padata: Fix pd UAF once and for allThere is a race condition/UAF in padata_reorder that goes backto the initial commit. A reference count is taken at the startof the process in padata_do_parallel, and released at the end inpadata_serial_worker.This reference count is (and only is) required for padata_replaceto function correctly. If padata_replace is never called thenthere is no issue.In the function padata_reorder which serves as the core of padata,as soon as padata is added to queue->serial.list, and the associatedspin lock released, that padata may be processed and the referencecount on pd would go away.Fix this by getting the next padata before the squeue->serial lockis released.In order to make this possible, simplify padata_reorder by onlycalling it once the next padata arrives.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38700 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: libiscsi: Initialize iscsi_conn->dd_data only if memory is allocatedIn case of an ib_fast_reg_mr allocation failure during iSER setup, themachine hits a panic because iscsi_conn->dd_data is initializedunconditionally, even when no memory is allocated (dd_size == 0). Thisleads invalid pointer dereference during connection teardown.Fix by setting iscsi_conn->dd_data only if memory is actually allocated.Panic trace:------------ iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12 iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swake_up_locked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0 [ib_iser] iscsi_stop_conn+0x66/0xc0 [scsi_transport_iscsi] iscsi_if_stop_conn+0x14a/0x150 [scsi_transport_iscsi] iscsi_if_rx+0x1135/0x1834 [scsi_transport_iscsi] ? netlink_lookup+0x12f/0x1b0 ? netlink_deliver_tap+0x2c/0x200 netlink_unicast+0x1ab/0x280 netlink_sendmsg+0x257/0x4f0 ? _copy_from_user+0x29/0x60 sock_sendmsg+0x5f/0x70

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38732 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject: don't leak dst refcount for loopback packetsrecent patches to add a WARN() when replacing skb dst entry found anold bug:WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234[..]Call Trace: nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325 nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27 expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline] ..This is because blamed commit forgot about loopback packets.Such packets already have a dst_entry attached, even at PRE_ROUTING stage.Instead of checking hook just check if the skb already has a routeattached to it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39838 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: prevent NULL pointer dereference in UTF16 conversionThere can be a NULL pointer dereference bug here. NULL is passed to__cifs_sfu_make_node without checks, which passes it unchecked tocifs_strndup_to_utf16, which in turn passes it tocifs_local_to_utf16_bytes where '*from' is dereferenced, causing a crash.This patch adds a check for NULL 'src' in cifs_strndup_to_utf16 andreturns NULL early to prevent dereferencing NULL pointer.Found by Linux Verification Center (linuxtesting.org) with SVACE

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39961 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/pgtbl: Fix possible race while increase page table levelThe AMD IOMMU host page table implementation supports dynamic page table levels(up to 6 levels), starting with a 3-level configuration that expands based onIOVA address. The kernel maintains a root pointer and current page table levelto enable proper page table walks in alloc_pte()/fetch_pte() operations.The IOMMU IOVA allocator initially starts with 32-bit address and onces itsexhuasted it switches to 64-bit address (max address is determined basedon IOMMU and device DMA capability). To support larger IOVA, AMD IOMMUdriver increases page table level.But in unmap path (iommu_v1_unmap_pages()), fetch_pte() readspgtable->[root/mode] without lock. So its possible that in exteme corner case,when increase_address_space() is updating pgtable->[root/mode], fetch_pte()reads wrong page table level (pgtable->mode). It does compare the value withlevel encoded in page table and returns NULL. This will result isiommu_unmap ops to fail and upper layer may retry/log WARN_ON.CPU 0 CPU 1------ ------map pages unmap pagesalloc_pte() -> increase_address_space() iommu_v1_unmap_pages() -> fetch_pte() pgtable->root = pte (new root value) READ pgtable->[mode/root] Reads new root, old mode Updates mode (pgtable->mode += 1)Since Page table level updates are infrequent and already synchronized with aspinlock, implement seqcount to enable lock-free read operations on the read path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40001 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mvsas: Fix use-after-free bugs in mvs_work_queueDuring the detaching of Marvell's SAS/SATA controller, the original codecalls cancel_delayed_work() in mvs_free() to cancel the delayed workitem mwq->work_q. However, if mwq->work_q is already running, thecancel_delayed_work() may fail to cancel it. This can lead touse-after-free scenarios where mvs_free() frees the mvs_info whilemvs_work_queue() is still executing and attempts to access thealready-freed mvs_info.A typical race condition is illustrated below:CPU 0 (remove) | CPU 1 (delayed work callback)mvs_pci_remove() | mvs_free() | mvs_work_queue() cancel_delayed_work() | kfree(mvi) | | mvi-> // UAFReplace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled and any executingdelayed work item completes before the mvs_info is deallocated.This bug was found by static analysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40005 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:spi: cadence-quadspi: Implement refcount to handle unbind during busydriver support indirect read and indirect write operation withassumption no force device removal(unbind) operation. Howeverforce device removal(removal) is still available to root superuser.Unbinding driver during operation causes kernel crash. This changesensure driver able to handle such operation for indirect read andindirect write by implementing refcount to track attached devicesto the controller and gracefully wait and until attached devicesremove operation completed before proceed with removal operation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68795 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Avoid overflowing userspace buffer on stats queryThe ethtool -S command operates across three ioctl calls:ETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, andETHTOOL_GSTATS for the values.If the number of stats changes between these calls (e.g., due to devicereconfiguration), userspace's buffer allocation will be incorrect,potentially leading to buffer overflow.Drivers are generally expected to maintain stable stat counts, but somedrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, makingthis scenario possible.Some drivers try to handle this internally:- bnad_get_ethtool_stats() returns early in case stats.n_stats is not equal to the driver's stats count.- micrel/ksz884x also makes sure not to write anything beyond stats.n_stats and overflow the buffer.However, both use stats.n_stats which is already assigned with the valuereturned from get_sset_count(), hence won't solve the issue describedhere.Change ethtool_get_strings(), ethtool_get_stats(),ethtool_get_phy_stats() to not return anything in case of a mismatchbetween userspace's size and get_sset_size(), to prevent bufferoverflow.The returned n_stats value will be equal to zero, to reflect thatnothing has been returned.This could result in one of two cases when using upstream ethtool,depending on when the size change is detected:1. When detected in ethtool_get_strings(): # ethtool -S eth2 no stats available2. When detected in get stats, all stats will be reported as zero.Both cases are presumably transient, and a subsequent ethtool callshould succeed.Other than the overflow avoidance, these two cases are very evident (nooutput/cleared stats), which is arguably better than presentingincorrect/shifted stats.I also considered returning an error instead of a "silent" response, butthat seems more destructive towards userspace apps.Notes:- This patch does not claim to fix the inherent race, it only makes sure that we do not overflow the userspace buffer, and makes for a more predictable behavior.- RTNL lock is held during each ioctl, the race window exists between the separate ioctl calls when the lock is released.- Userspace ethtool always fills stats.n_stats, but it is likely that these stats ioctls are implemented in other userspace applications which might not fill it. The added code checks that it's not zero, to prevent any regressions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-21546 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix WRITE_SAME No Data Buffer crashIn newer version of the SBC specs, we have a NDOB bit that indicates thereis no data buffer that gets written out. If this bit is set using commandslike "sg_write_same --ndob" we will crash in target_core_iblock/file'sexecute_write_same handlers when we go to access the se_cmd->t_data_sgbecause its NULL.This patch adds a check for the NDOB bit in the common WRITE SAME codebecause we don't support it. And, it adds a check for zero SG elements ineach handler in case the initiator tries to send a normal WRITE SAME withno data buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-34324 Severity: Moderate CVSS3 score: 5.7

Description: Closing of an event channel in the Linux kernel can result in a deadlock.This happens when the close is being performed in parallel to an unrelatedXen console action and the handling of a Xen console interrupt in anunprivileged guest.The closing of an event channel is e.g. triggered by removal of aparavirtual device on the other side. As this action will cause consolemessages to be issued on the other side quite often, the chance oftriggering the deadlock is not neglectable.Note that 32-bit Arm-guests are not affected, as the 32-bit Linux kernelon Arm doesn't use queued-RW-locks, which are required to trigger theissue (on Arm32 a waiting writer doesn't block further readers to getthe lock).

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2023-52593 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'should check the return value before examining skb data. So convertthe latter to return an appropriate error code and propagate it toreturn from 'wfx_start_ap()' as well. Compile tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38565 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: enable proper endpoint verificationSyzkaller reports [1] hitting a warning about an endpoint in usenot having an expected type to it.Fix the issue by checking for the existence of all properendpoints with their according types intact.Sadly, this patch has not been tested on real hardware.[1] Syzkaller report:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline] ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline] ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293 call_driver_probe drivers/base/dd.c:560 [inline] really_probe+0x249/0xb90 drivers/base/dd.c:639 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487 device_add+0xbd9/0x1e90 drivers/base/core.c:3517 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573 hub_port_connect drivers/usb/core/hub.c:5353 [inline] hub_port_connect_change drivers/usb/core/hub.c:5497 [inline] port_event drivers/usb/core/hub.c:5653 [inline] hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289 worker_thread+0x669/0x1090 kernel/workqueue.c:2436 kthread+0x2e8/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56590 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix not checking skb length on hci_acldata_packetThis fixes not checking if skb really contains an ACL header otherwisethe code may attempt to access some uninitilized/invalid memory past thevalid skb->data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68736 Severity: Moderate CVSS3 score: 5.7

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Fix handling of disconnected directoriesDisconnected files or directories can appear when they are visible andopened from a bind mount, but have been renamed or moved from the sourceof the bind mount in a way that makes them inaccessible from the mountpoint (i.e. out of scope).Previously, access rights tied to files or directories opened through adisconnected directory were collected by walking the related hierarchydown to the root of the filesystem, without taking into account themount point because it couldn't be found. This could lead toinconsistent access results, potential access right widening, andhard-to-debug renames, especially since such paths cannot be printed.For a sandboxed task to create a disconnected directory, it needs tohave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) tothe underlying source of the bind mount, and read access to the relatedmount point. Because a sandboxed task cannot acquire more accessrights than those defined by its Landlock domain, this could lead toinconsistent access rights due to missing permissions that should beinherited from the mount point hierarchy, while inheriting permissionsfrom the filesystem hierarchy hidden by this mount point instead.Landlock now handles files and directories opened from disconnecteddirectories by taking into account the filesystem hierarchy when themount point is not found in the hierarchy walk, and also always takinginto account the mount point from which these disconnected directorieswere opened. This ensures that a rename is not allowed if it wouldwiden access rights [1].The rationale is that, even if disconnected hierarchies might not bevisible or accessible to a sandboxed task, relying on the collectedaccess rights from them improves the guarantee that access rights willnot be widened during a rename because of the access right comparisonbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).It may look like this would grant more access on disconnected files anddirectories, but the security policies are always enforced for all theevaluated hierarchies. This new behavior should be less surprising tousers and safer from an access control perspective.Remove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() andfix the related comment.Because opened files have their access rights stored in the related filesecurity properties, there is no impact for disconnected or unlinkedfiles.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-28956 Severity: Moderate CVSS3 score: 5.6

Description: Exposure of Sensitive Information in Shared Microarchitectural Structures during Transient Execution for some Intel(R) Processors may allow an authenticated user to potentially enable information disclosure via local access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35875 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:x86/coco: Require seeding RNG with RDRAND on CoCo systemsThere are few uses of CoCo that don't rely on working cryptography andhence a working RNG. Unfortunately, the CoCo threat model means that theVM host cannot be trusted and may actively work against guests toextract secrets or manipulate computation. Since a malicious host canmodify or observe nearly all inputs to guests, the only remaining sourceof entropy for CoCo guests is RDRAND.If RDRAND is broken -- due to CPU hardware fault -- the RNG as a wholeis meant to gracefully continue on gathering entropy from other sources,but since there aren't other sources on CoCo, this is catastrophic.This is mostly a concern at boot time when initially seeding the RNG, asafter that the consequences of a broken RDRAND are much moretheoretical.So, try at boot to seed the RNG using 256 bits of RDRAND output. If thisfails, panic(). This will also trigger if the system is booted withoutRDRAND, as RDRAND is essential for a safe CoCo boot.Add this deliberately to be "just a CoCo x86 driver feature" and notpart of the RNG itself. Many device drivers and platforms have somedesire to contribute something to the RNG, and add_device_randomness()is specifically meant for this purpose.Any driver can call it with seed data of any quality, or even garbagequality, and it can only possibly make the quality of the RNG better orhave no effect, but can never make it worse.Rather than trying to build something into the core of the RNG, considerthe particular CoCo issue just a CoCo issue, and therefore separate itall out into driver (well, arch/platform) code. [ bp: Massage commit message. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36965 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: mediatek: Make sure IPI buffer fits in L2TCMThe IPI buffer location is read from the firmware that we load to theSystem Companion Processor, and it's not granted that both the SRAM(L2TCM) size that is defined in the devicetree node is large enoughfor that, and while this is especially true for multi-core SCP, it'sstill useful to check on single-core variants as well.Failing to perform this check may make this driver perform R/Woperations out of the L2TCM boundary, resulting (at best) in akernel panic.To fix that, check that the IPI buffer fits, otherwise return afailure and refuse to boot the relevant SCP core (or the SCP atall, if this is single core).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44974 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-0838 Severity: Moderate CVSS3 score: 5.6

Description: There exists a heap buffer overflow vulnerable in Abseil-cpp. The sized constructors, reserve(), and rehash() methods of absl::{flat,node}hash{set,map} did not impose an upper bound on their size argument. As a result, it was possible for a caller to pass a very large size that would cause an integer overflow when computing the size of the container's backing store, and a subsequent out-of-bounds memory write. Subsequent accesses to the container might also access out-of-bounds memory. We recommend upgrading past commit 5a0e2cb5e3958dd90bb8569a2766622cb74d90c1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libabsl2308_0_0 > 0-0 (version in image is 20230802.1-150400.10.4.1).

CVE-2025-32414 Severity: Moderate CVSS3 score: 5.6

Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, out-of-bounds memory access can occur in the Python API (Python bindings) because of an incorrect return value. This occurs in xmlPythonFileRead and xmlPythonFileReadRaw because of a difference between bytes and characters.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2025-38422 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Modify the EEPROM and OTP size for PCI1xxxx devicesMaximum OTP and EEPROM size for hearthstone PCI1xxxx devices are 8 Kband 64 Kb respectively. Adjust max size definitions and return correctEEPROM length based on device. Also prevent out-of-bound read/write.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-55158 Severity: Moderate CVSS3 score: 5.6

Description: Vim is an open source, command line text editor. In versions from 9.1.1231 to before 9.1.1406, when processing nested tuples during Vim9 script import operations, an error during evaluation can trigger a double-free in Vim's internal typed value (typval_T) management. Specifically, the clear_tv() function may attempt to free memory that has already been deallocated, due to improper lifetime handling in the handle_import / ex_import code paths. The vulnerability can only be triggered if a user explicitly opens and executes a specially crafted Vim script. This issue has been patched in version 9.1.1406.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-71087 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: fix off-by-one issues in iavf_config_rss_reg()There are off-by-one bugs when configuring RSS hash key and lookuptable, causing out-of-bounds reads to memory [1] and out-of-boundswrites to device registers.Before commit 43a3d9ba34c9 ("i40evf: Allow PF driver to configure RSS"),the loop upper bounds were: i <= I40E_VFQF_{HKEY,HLUT}_MAX_INDEXwhich is safe since the value is the last valid index.That commit changed the bounds to: i <= adapter->rss_{key,lut}_size / 4where `rss_{key,lut}_size / 4` is the number of dwords, so the lastvalid index is `(rss_{key,lut}_size / 4) - 1`. Therefore, using `<=`accesses one element past the end.Fix the issues by using `<` instead of `<=`, ensuring we do not exceedthe bounds.[1] KASAN splat about rss_key_size off-by-one BUG: KASAN: slab-out-of-bounds in iavf_config_rss+0x619/0x800 Read of size 4 at addr ffff888102c50134 by task kworker/u8:6/63 CPU: 0 UID: 0 PID: 63 Comm: kworker/u8:6 Not tainted 6.18.0-rc2-enjuk-tnguy-00378-g3005f5b77652-dirty #156 PREEMPT(voluntary) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Workqueue: iavf iavf_watchdog_task Call Trace: dump_stack_lvl+0x6f/0xb0 print_report+0x170/0x4f3 kasan_report+0xe1/0x1a0 iavf_config_rss+0x619/0x800 iavf_watchdog_task+0x2be7/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 Allocated by task 63: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 __kmalloc_noprof+0x246/0x6f0 iavf_watchdog_task+0x28fc/0x3230 process_one_work+0x7fd/0x1420 worker_thread+0x4d1/0xd40 kthread+0x344/0x660 ret_from_fork+0x249/0x320 ret_from_fork_asm+0x1a/0x30 The buggy address belongs to the object at ffff888102c50100 which belongs to the cache kmalloc-64 of size 64 The buggy address is located 0 bytes to the right of allocated 52-byte region [ffff888102c50100, ffff888102c50134) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x102c50 flags: 0x200000000000000(node=0|zone=2) page_type: f5(slab) raw: 0200000000000000 ffff8881000418c0 dead000000000122 0000000000000000 raw: 0000000000000000 0000000080200020 00000000f5000000 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888102c50000: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc ffff888102c50080: 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc >ffff888102c50100: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc ^ ffff888102c50180: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc ffff888102c50200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71102 Severity: Moderate CVSS3 score: 5.6

Description: In the Linux kernel, the following vulnerability has been resolved:scs: fix a wrong parameter in __scs_magic__scs_magic() needs a 'void *' variable, but a 'struct task_struct *' isgiven. 'task_scs(tsk)' is the starting address of the task's shadow callstack, and '__scs_magic(task_scs(tsk))' is the end address of the task'sshadow call stack. Here should be '__scs_magic(task_scs(tsk))'.The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGEis enabled, the shadow call stack usage checking function(scs_check_usage) would scan an incorrect memory range. This could lead1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg.2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses).However, since this is purely a debugging feature(CONFIG_DEBUG_STACK_USAGE), normal production systems should be notunaffected. The bug only impacts developers and testers who are activelydebugging stack usage with this configuration enabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2020-13631 Severity: Moderate CVSS3 score: 5.5

Description: SQLite before 3.32.0 allows a virtual table to be renamed to the name of one of its shadow tables, related to alter.c and build.c.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2021-47214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlb, userfaultfd: fix reservation restore on userfaultfd errorCurrently in the is_continue case in hugetlb_mcopy_atomic_pte(), if webail out using "goto out_release_unlock;" in the cases where idx >=size, or !huge_pte_none(), the code will detect that new_pagecache_page== false, and so call restore_reserve_on_error(). In this case I seerestore_reserve_on_error() delete the reservation, and the followingcall to remove_inode_hugepages() will increment h->resv_hugepagescausing a 100% reproducible leak.We should treat the is_continue case similar to adding a page into thepagecache and set new_pagecache_page to true, to indicate that there isno reservation to restore on the error path, and we need not callrestore_reserve_on_error(). Rename new_pagecache_page topage_in_pagecache to make that clear.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47432 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/generic-radix-tree.c: Don't overflow in peek()When we started spreading new inode numbers throughout most of the 64bit inode space, that triggered some corner case bugs, in particularsome integer overflows related to the radix tree code. Oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47512 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: prevent dismantle issueFor some reason, fq_pie_destroy() did not copyworking code from pie_destroy() and other qdiscs,thus causing elusive bug.Before calling del_timer_sync(&q->adapt_timer),we need to ensure timer will not rearm itself.rcu: INFO: rcu_preempt self-detected stall on CPUrcu: 0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579 (t=10501 jiffies g=13085 q=3989)NMI backtrace for cpu 0CPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62 trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline] rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343 print_cpu_stall kernel/rcu/tree_stall.h:627 [inline] check_cpu_stall kernel/rcu/tree_stall.h:711 [inline] rcu_pending kernel/rcu/tree.c:3878 [inline] rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597 update_process_times+0x16d/0x200 kernel/time/timer.c:1785 tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226 tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428 __run_hrtimer kernel/time/hrtimer.c:1685 [inline] __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749 hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811 local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline] __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103 sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638RIP: 0010:write_comp_data kernel/kcov.c:221 [inline]RIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273Code: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00RSP: 0018:ffffc90000d27b28 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000RDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003RBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000R13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000 pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418 fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383 call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421 expire_timers kernel/time/timer.c:1466 [inline] __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734 __run_timers kernel/time/timer.c:1715 [inline] run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747 __do_softirq+0x29b/0x9c2 kernel/softirq.c:558 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164 kthread+0x405/0x4f0 kernel/kthread.c:327 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47515 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:seg6: fix the iif in the IPv6 socket control blockWhen an IPv4 packet is received, the ip_rcv_core(...) sets the receivinginterface index into the IPv4 socket control block (v5.16-rc4,net/ipv4/ip_input.c line 510): IPCB(skb)->iif = skb->skb_iif;If that IPv4 packet is meant to be encapsulated in an outer IPv6+SRHheader, the seg6_do_srh_encap(...) performs the required encapsulation.In this case, the seg6_do_srh_encap function clears the IPv6 socket controlblock (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163): memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));The memset(...) was introduced in commit ef489749aae5 ("ipv6: sr: clearIP6CB(skb) on SRH ip4ip6 encapsulation") a long time ago (2019-01-29).Since the IPv6 socket control block and the IPv4 socket control block sharethe same memory area (skb->cb), the receiving interface index info is lost(IP6CB(skb)->iif is set to zero).As a side effect, that condition triggers a NULL pointer dereference ifcommit 0857d6f8c759 ("ipv6: When forwarding count rx stats on the orignetdev") is applied.To fix that issue, we set the IP6CB(skb)->iif with the index of thereceiving interface once again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sit: do not call ipip6_dev_free() from sit_init_net()ipip6_dev_free is sit dev->priv_destructor, already calledby register_netdevice() if something goes wrong.Alternative would be to make ipip6_dev_free() robust againstmultiple invocations, but other drivers do not implement thisstrategy.syzbot reported:dst_release underflowWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173Modules linked in:CPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173Code: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48RSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246RAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000RDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000RBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2cR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358R13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000FS: 00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160 ipip6_dev_free net/ipv6/sit.c:1414 [inline] sit_init_net+0x229/0x550 net/ipv6/sit.c:1936 ops_init+0x313/0x430 net/core/net_namespace.c:140 setup_net+0x35b/0x9d0 net/core/net_namespace.c:326 copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470 create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226 ksys_unshare+0x57d/0xb50 kernel/fork.c:3075 __do_sys_unshare kernel/fork.c:3146 [inline] __se_sys_unshare kernel/fork.c:3144 [inline] __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f66c882ce99Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200RBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix deadlock in __mptcp_push_pending()__mptcp_push_pending() may call mptcp_flush_join_list() with subflowsocket lock held. If such call hits mptcp_sockopt_sync_all() thensubsequently __mptcp_sockopt_sync() could try to lock the subflowsocket for itself, causing a deadlock.sysrq: Show Blocked Statetask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000Call Trace: __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160 ? do_wait_intr_irq+0xa0/0xa0 ? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f9ba546c2d0RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8 Fix the issue by using __mptcp_flush_join_list() instead of plainmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested byFlorian. The sockopt sync will be deferred to the workqueue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47591 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: remove tcp ulp setsockopt supportTCP_ULP setsockopt cannot be used for mptcp because its alreadyused internally to plumb subflow (tcp) sockets to the mptcp layer.syzbot managed to trigger a crash for mptcp connections that arein fallback mode:KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]CPU: 1 PID: 1083 Comm: syz-executor.3 Not tainted 5.16.0-rc2-syzkaller #0RIP: 0010:tls_build_proto net/tls/tls_main.c:776 [inline][..] __tcp_set_ulp net/ipv4/tcp_ulp.c:139 [inline] tcp_set_ulp+0x428/0x4c0 net/ipv4/tcp_ulp.c:160 do_tcp_setsockopt+0x455/0x37c0 net/ipv4/tcp.c:3391 mptcp_setsockopt+0x1b47/0x2400 net/mptcp/sockopt.c:638Remove support for TCP_ULP setsockopt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: clear 'kern' flag from fallback socketsThe mptcp ULP extension relies on sk->sk_sock_kern being set correctly:It prevents setsockopt(fd, IPPROTO_TCP, TCP_ULP, "mptcp", 6); fromworking for plain tcp sockets (any userspace-exposed socket).But in case of fallback, accept() can return a plain tcp sk.In such case, sk is still tagged as 'kernel' and setsockopt will work.This will crash the kernel, The subflow extension has a NULL ctx->connmptcp socket:BUG: KASAN: null-ptr-deref in subflow_data_ready+0x181/0x2b0Call Trace: tcp_data_ready+0xf8/0x370 [..]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: never allow the PM to close a listener subflowCurrently, when deleting an endpoint the netlink PM treversesall the local MPTCP sockets, regardless of their status.If an MPTCP listener socket is bound to the IP matching thedelete endpoint, the listener TCP socket will be closed.That is unexpected, the PM should only affect data subflows.Additionally, syzbot was able to trigger a NULL ptr dereferencedue to the above:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]CPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897Code: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ffRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016RAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000RDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001R10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000R13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001FS: 00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0Call Trace: lock_acquire kernel/locking/lockdep.c:5637 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162 finish_wait+0xc0/0x270 kernel/sched/wait.c:400 inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline] inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497 mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865 inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739 mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345 do_accept+0x382/0x510 net/socket.c:1773 __sys_accept4_file+0x7e/0xe0 net/socket.c:1816 __sys_accept4+0xb0/0x100 net/socket.c:1846 __do_sys_accept net/socket.c:1864 [inline] __se_sys_accept net/socket.c:1861 [inline] __x64_sys_accept+0x71/0xb0 net/socket.c:1861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f177cd8b8e9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002bRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340cR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000 Fix the issue explicitly skipping MPTCP socket in TCP_LISTENstatus.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47599 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: use latest_dev in btrfs_show_devnameThe test case btrfs/238 reports the warning below: WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs] CPU: 2 PID: 1 Comm: systemd Tainted: G W O 5.14.0-rc1-custom #72 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: btrfs_show_devname+0x108/0x1b4 [btrfs] show_mountinfo+0x234/0x2c4 m_show+0x28/0x34 seq_read_iter+0x12c/0x3c4 vfs_read+0x29c/0x2c8 ksys_read+0x80/0xec __arm64_sys_read+0x28/0x34 invoke_syscall+0x50/0xf8 do_el0_svc+0x88/0x138 el0_svc+0x2c/0x8c el0t_64_sync_handler+0x84/0xe4 el0t_64_sync+0x198/0x19cReason:While btrfs_prepare_sprout() moves the fs_devices::devices intofs_devices::seed_list, the btrfs_show_devname() searches for the devicesand found none, leading to the warning as in above.Fix:latest_dev is updated according to the changes to the device list.That means we could use the latest_dev->name to show the device name in/proc/self/mounts, the pointer will be always valid as it's assignedbefore the device is deleted from the list in remove or replace.The RCU protection is sufficient as the device structure is freed aftersynchronization.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netlink: af_netlink: Prevent empty skb by adding a check on len.Adding a check on len parameter to avoid empty skb. This prevents adivision error in netem_enqueue function which is caused when skb->len=0and skb->data_len=0 in the randomized corruption step as shown below.skb->data[prandom_u32() % skb_headlen(skb)] ^= 1<<(prandom_u32() % 8);Crash Report:[ 343.170349] netdevsim netdevsim0 netdevsim3: set [1, 0] type 2 family0 port 6081 - 0[ 343.216110] netem: version 1.3[ 343.235841] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI[ 343.236680] CPU: 3 PID: 4288 Comm: reproducer Not tainted 5.16.0-rc1+[ 343.237569] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS 1.11.0-2.el7 04/01/2014[ 343.238707] RIP: 0010:netem_enqueue+0x1590/0x33c0 [sch_netem][ 343.239499] Code: 89 85 58 ff ff ff e8 5f 5d e9 d3 48 8b b5 48 ff ffff 8b 8d 50 ff ff ff 8b 85 58 ff ff ff 48 8b bd 70 ff ff ff 31 d2 2b 4f74 f1 48 b8 00 00 00 00 00 fc ff df 49 01 d5 4c 89 e9 48 c1 e9 03[ 343.241883] RSP: 0018:ffff88800bcd7368 EFLAGS: 00010246[ 343.242589] RAX: 00000000ba7c0a9c RBX: 0000000000000001 RCX:0000000000000000[ 343.243542] RDX: 0000000000000000 RSI: ffff88800f8edb10 RDI:ffff88800f8eda40[ 343.244474] RBP: ffff88800bcd7458 R08: 0000000000000000 R09:ffffffff94fb8445[ 343.245403] R10: ffffffff94fb8336 R11: ffffffff94fb8445 R12:0000000000000000[ 343.246355] R13: ffff88800a5a7000 R14: ffff88800a5b5800 R15:0000000000000020[ 343.247291] FS: 00007fdde2bd7700(0000) GS:ffff888109780000(0000)knlGS:0000000000000000[ 343.248350] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 343.249120] CR2: 00000000200000c0 CR3: 000000000ef4c000 CR4:00000000000006e0[ 343.250076] Call Trace:[ 343.250423] [ 343.250713] ? memcpy+0x4d/0x60[ 343.251162] ? netem_init+0xa0/0xa0 [sch_netem][ 343.251795] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.252443] netem_enqueue+0xe28/0x33c0 [sch_netem][ 343.253102] ? stack_trace_save+0x87/0xb0[ 343.253655] ? filter_irq_stacks+0xb0/0xb0[ 343.254220] ? netem_init+0xa0/0xa0 [sch_netem][ 343.254837] ? __kasan_check_write+0x14/0x20[ 343.255418] ? _raw_spin_lock+0x88/0xd6[ 343.255953] dev_qdisc_enqueue+0x50/0x180[ 343.256508] __dev_queue_xmit+0x1a7e/0x3090[ 343.257083] ? netdev_core_pick_tx+0x300/0x300[ 343.257690] ? check_kcov_mode+0x10/0x40[ 343.258219] ? _raw_spin_unlock_irqrestore+0x29/0x40[ 343.258899] ? __kasan_init_slab_obj+0x24/0x30[ 343.259529] ? setup_object.isra.71+0x23/0x90[ 343.260121] ? new_slab+0x26e/0x4b0[ 343.260609] ? kasan_poison+0x3a/0x50[ 343.261118] ? kasan_unpoison+0x28/0x50[ 343.261637] ? __kasan_slab_alloc+0x71/0x90[ 343.262214] ? memcpy+0x4d/0x60[ 343.262674] ? write_comp_data+0x2f/0x90[ 343.263209] ? __kasan_check_write+0x14/0x20[ 343.263802] ? __skb_clone+0x5d6/0x840[ 343.264329] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.264958] dev_queue_xmit+0x1c/0x20[ 343.265470] netlink_deliver_tap+0x652/0x9c0[ 343.266067] netlink_unicast+0x5a0/0x7f0[ 343.266608] ? netlink_attachskb+0x860/0x860[ 343.267183] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.267820] ? write_comp_data+0x2f/0x90[ 343.268367] netlink_sendmsg+0x922/0xe80[ 343.268899] ? netlink_unicast+0x7f0/0x7f0[ 343.269472] ? __sanitizer_cov_trace_pc+0x21/0x60[ 343.270099] ? write_comp_data+0x2f/0x90[ 343.270644] ? netlink_unicast+0x7f0/0x7f0[ 343.271210] sock_sendmsg+0x155/0x190[ 343.271721] ____sys_sendmsg+0x75f/0x8f0[ 343.272262] ? kernel_sendmsg+0x60/0x60[ 343.272788] ? write_comp_data+0x2f/0x90[ 343.273332] ? write_comp_data+0x2f/0x90[ 343.273869] ___sys_sendmsg+0x10f/0x190[ 343.274405] ? sendmsg_copy_msghdr+0x80/0x80[ 343.274984] ? slab_post_alloc_hook+0x70/0x230[ 343.275597] ? futex_wait_setup+0x240/0x240[ 343.276175] ? security_file_alloc+0x3e/0x170[ 343.276779] ? write_comp_d---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48639 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix possible refcount leak in tc_new_tfilter()tfilter_put need to be called to put the refount got by tp->ops->get toavoid possible refcount leak when chain->tmplt_ops != NULL andchain->tmplt_ops != tp->ops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix NULL deref in bond_rr_gen_slave_idFix a NULL dereference of the struct bonding.rr_tx_counter member becauseif a bond is initially created with an initial mode != zero (Round Robin)the memory required for the counter is never created and when the mode ischanged there is never any attempt to verify the memory is allocated uponswitching modes.This causes the following Oops on an aarch64 machine: [ 334.686773] Unable to handle kernel paging request at virtual address ffff2c91ac905000 [ 334.694703] Mem abort info: [ 334.697486] ESR = 0x0000000096000004 [ 334.701234] EC = 0x25: DABT (current EL), IL = 32 bits [ 334.706536] SET = 0, FnV = 0 [ 334.709579] EA = 0, S1PTW = 0 [ 334.712719] FSC = 0x04: level 0 translation fault [ 334.717586] Data abort info: [ 334.720454] ISV = 0, ISS = 0x00000004 [ 334.724288] CM = 0, WnR = 0 [ 334.727244] swapper pgtable: 4k pages, 48-bit VAs, pgdp=000008044d662000 [ 334.733944] [ffff2c91ac905000] pgd=0000000000000000, p4d=0000000000000000 [ 334.740734] Internal error: Oops: 96000004 [#1] SMP [ 334.745602] Modules linked in: bonding tls veth rfkill sunrpc arm_spe_pmu vfat fat acpi_ipmi ipmi_ssif ixgbe igb i40e mdio ipmi_devintf ipmi_msghandler arm_cmn arm_dsu_pmu cppc_cpufreq acpi_tad fuse zram crct10dif_ce ast ghash_ce sbsa_gwdt nvme drm_vram_helper drm_ttm_helper nvme_core ttm xgene_hwmon [ 334.772217] CPU: 7 PID: 2214 Comm: ping Not tainted 6.0.0-rc4-00133-g64ae13ed4784 #4 [ 334.779950] Hardware name: GIGABYTE R272-P31-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021 [ 334.789244] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 334.796196] pc : bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.801691] lr : bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.807962] sp : ffff8000221733e0 [ 334.811265] x29: ffff8000221733e0 x28: ffffdbac8572d198 x27: ffff80002217357c [ 334.818392] x26: 000000000000002a x25: ffffdbacb33ee000 x24: ffff07ff980fa000 [ 334.825519] x23: ffffdbacb2e398ba x22: ffff07ff98102000 x21: ffff07ff981029c0 [ 334.832646] x20: 0000000000000001 x19: ffff07ff981029c0 x18: 0000000000000014 [ 334.839773] x17: 0000000000000000 x16: ffffdbacb1004364 x15: 0000aaaabe2f5a62 [ 334.846899] x14: ffff07ff8e55d968 x13: ffff07ff8e55db30 x12: 0000000000000000 [ 334.854026] x11: ffffdbacb21532e8 x10: 0000000000000001 x9 : ffffdbac857178ec [ 334.861153] x8 : ffff07ff9f6e5a28 x7 : 0000000000000000 x6 : 000000007c2b3742 [ 334.868279] x5 : ffff2c91ac905000 x4 : ffff2c91ac905000 x3 : ffff07ff9f554400 [ 334.875406] x2 : ffff2c91ac905000 x1 : 0000000000000001 x0 : ffff07ff981029c0 [ 334.882532] Call trace: [ 334.884967] bond_rr_gen_slave_id+0x40/0x124 [bonding] [ 334.890109] bond_xmit_roundrobin_slave_get+0x38/0xdc [bonding] [ 334.896033] __bond_start_xmit+0x128/0x3a0 [bonding] [ 334.901001] bond_start_xmit+0x54/0xb0 [bonding] [ 334.905622] dev_hard_start_xmit+0xb4/0x220 [ 334.909798] __dev_queue_xmit+0x1a0/0x720 [ 334.913799] arp_xmit+0x3c/0xbc [ 334.916932] arp_send_dst+0x98/0xd0 [ 334.920410] arp_solicit+0xe8/0x230 [ 334.923888] neigh_probe+0x60/0xb0 [ 334.927279] __neigh_event_send+0x3b0/0x470 [ 334.931453] neigh_resolve_output+0x70/0x90 [ 334.935626] ip_finish_output2+0x158/0x514 [ 334.939714] __ip_finish_output+0xac/0x1a4 [ 334.943800] ip_finish_output+0x40/0xfc [ 334.947626] ip_output+0xf8/0x1a4 [ 334.950931] ip_send_skb+0x5c/0x100 [ 334.954410] ip_push_pending_frames+0x3c/0x60 [ 334.958758] raw_sendmsg+0x458/0x6d0 [ 334.962325] inet_sendmsg+0x50/0x80 [ 334.965805] sock_sendmsg+0x60/0x6c [ 334.969286] __sys_sendto+0xc8/0x134 [ 334.972853] __arm64_sys_sendto+0x34/0x4c---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: avoid disabling offload when it was never enabledIn an incredibly strange API design decision, qdisc->destroy() getscalled even if qdisc->init() never succeeded, not exclusively sincecommit 87b60cfacf9f ("net_sched: fix error recovery at qdisc creation"),but apparently also earlier (in the case of qdisc_create_dflt()).The taprio qdisc does not fully acknowledge this when it attempts fulloffload, because it starts off with q->flags = TAPRIO_FLAGS_INVALID intaprio_init(), then it replaces q->flags with TCA_TAPRIO_ATTR_FLAGSparsed from netlink (in taprio_change(), tail called from taprio_init()).But in taprio_destroy(), we call taprio_disable_offload(), and thisdetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q->flags).But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()(a bitwise check of bit 1 in q->flags), it is invalid to call this macroon q->flags when it contains TAPRIO_FLAGS_INVALID, because that is setto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true onan invalid set of flags.As a result, it is possible to crash the kernel if user space forces anerror between setting q->flags = TAPRIO_FLAGS_INVALID, and the callingof taprio_enable_offload(). This is because drivers do not expect theoffload to be disabled when it was never enabled.The error that we force here is to attach taprio as a non-root qdisc,but instead as child of an mqprio root qdisc:$ tc qdisc add dev swp0 root handle 1: \ mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0$ tc qdisc replace dev swp0 parent 1:1 \ taprio num_tc 8 map 0 1 2 3 4 5 6 7 \ queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \ sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \ flags 0x0 clockid CLOCK_TAIUnable to handle kernel paging request at virtual address fffffffffffffff8[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPCall trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2cFix this by keeping track of the operations we made, and undo theoffload only if we actually did it.I've added "bool offloaded" inside a 4 byte hole between "int clockid"and "atomic64_t picos_per_byte". Now the first cache line looks likebelow:$ pahole -C taprio_sched net/sched/sch_taprio.ostruct taprio_sched { struct Qdisc * * qdiscs; /* 0 8 */ struct Qdisc * root; /* 8 8 */ u32 flags; /* 16 4 */ enum tk_offsets tk_offset; /* 20 4 */ int clockid; /* 24 4 */ bool offloaded; /* 28 1 */ /* XXX 3 bytes hole, try to pack */ atomic64_t picos_per_byte; /* 32 0 */ /* XXX 8 bytes hole, try to pack */ spinlock_t current_entry_lock; /* 40 0 */ /* XXX 8 bytes hole, try to pack */ struct sched_entry * current_entry; /* 48 8 */ struct sched_gate_list * oper_sched; /* 56 8 */ /* --- cacheline 1 boundary (64 bytes) --- */

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sfc/siena: fix null pointer dereference in efx_hard_start_xmitLike in previous patch for sfc, prevent potential (but unlikely) NULLpointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: slub: fix flush_cpu_slab()/__free_slab() invocations in task context.Commit 5a836bf6b09f ("mm: slub: move flush_cpu_slab() invocations__free_slab() invocations out of IRQ context") moved all flush_cpu_slab()invocations to the global workqueue to avoid a problem relatedwith deactivate_slab()/__free_slab() being called from an IRQ contexton PREEMPT_RT kernels.When the flush_all_cpu_locked() function is called from a task contextit may happen that a workqueue with WQ_MEM_RECLAIM bit set ends upflushing the global workqueue, this will cause a dependency issue. workqueue: WQ_MEM_RECLAIM nvme-delete-wq:nvme_delete_ctrl_work [nvme_core] is flushing !WQ_MEM_RECLAIM events:flush_cpu_slab WARNING: CPU: 37 PID: 410 at kernel/workqueue.c:2637 check_flush_dependency+0x10a/0x120 Workqueue: nvme-delete-wq nvme_delete_ctrl_work [nvme_core] RIP: 0010:check_flush_dependency+0x10a/0x120[ 453.262125] Call Trace: __flush_work.isra.0+0xbf/0x220 ? __queue_work+0x1dc/0x420 flush_all_cpus_locked+0xfb/0x120 __kmem_cache_shutdown+0x2b/0x320 kmem_cache_destroy+0x49/0x100 bioset_exit+0x143/0x190 blk_release_queue+0xb9/0x100 kobject_cleanup+0x37/0x130 nvme_fc_ctrl_free+0xc6/0x150 [nvme_fc] nvme_free_ctrl+0x1ac/0x2b0 [nvme_core]Fix this bug by creating a workqueue for the flush operation withthe WQ_MEM_RECLAIM bit set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix a use-after-freeThere are two .exit_cmd_priv implementations. Both implementations useresources associated with the SCSI host. Make sure that these resources arestill available when .exit_cmd_priv is called by waiting insidescsi_remove_host() until the tag set has been freed.This commit fixes the following use-after-free:==================================================================BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]Read of size 8 at addr ffff888100337000 by task multipathd/16727Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db kasan_report+0xab/0x120 srp_exit_cmd_priv+0x27/0xd0 [ib_srp] scsi_mq_exit_request+0x4d/0x70 blk_mq_free_rqs+0x143/0x410 __blk_mq_free_map_and_rqs+0x6e/0x100 blk_mq_free_tag_set+0x2b/0x160 scsi_host_dev_release+0xf3/0x1a0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_device_dev_release_usercontext+0x4c1/0x4e0 execute_in_process_context+0x23/0x90 device_release+0x54/0xe0 kobject_put+0xa5/0x120 scsi_disk_release+0x3f/0x50 device_release+0x54/0xe0 kobject_put+0xa5/0x120 disk_release+0x17f/0x1b0 device_release+0x54/0xe0 kobject_put+0xa5/0x120 dm_put_table_device+0xa3/0x160 [dm_mod] dm_put_device+0xd0/0x140 [dm_mod] free_priority_group+0xd8/0x110 [dm_multipath] free_multipath+0x94/0xe0 [dm_multipath] dm_table_destroy+0xa2/0x1e0 [dm_mod] __dm_destroy+0x196/0x350 [dm_mod] dev_remove+0x10c/0x160 [dm_mod] ctl_ioctl+0x2c2/0x590 [dm_mod] dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 dm_ctl_ioctl+0x5/0x10 [dm_mod] __x64_sys_ioctl+0xb4/0xf0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix potential memleak in papr_get_attr()`buf` is allocated in papr_get_attr(), and krealloc() of `buf`could fail. We need to free the original `buf` in the case of failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd938x: fix incorrect used of portidMixer controls have the channel id in mixer->reg, which is not sameas port id. port id should be derived from chan_info array.So fix this. Without this, its possible that we could corruptstruct wcd938x_sdw_priv by accessing port_map array out of rangewith channel id instead of port id.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: make sure to refresh master_dev/m_ops in __rtnl_newlink()While looking at one unrelated syzbot bug, I found the replay logicin __rtnl_newlink() to potentially trigger use-after-free.It is better to clear master_dev and m_ops inside the loop,in case we have to replay it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc64/bpf: Limit 'ldbrx' to processors compliant with ISA v2.06Johan reported the below crash with test_bpf on ppc64 e5500: test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -> 0x67452301 jited:1 Oops: Exception in kernel mode, sig: 4 [#1] BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500 Modules linked in: test_bpf(+) CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1 NIP: 8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18 REGS: c0000000032d3420 TRAP: 0700 Not tainted (5.14.0-03771-g98c2059e008a-dirty) MSR: 0000000080089000 CR: 88002822 XER: 20000000 IRQMASK: 0 <...> NIP [8000000000061c3c] 0x8000000000061c3c LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf] Call Trace: .__run_one+0x60/0x17c [test_bpf] (unreliable) .test_bpf_init+0x6a8/0xdc8 [test_bpf] .do_one_initcall+0x6c/0x28c .do_init_module+0x68/0x28c .load_module+0x2460/0x2abc .__do_sys_init_module+0x120/0x18c .system_call_exception+0x110/0x1b8 system_call_common+0xf0/0x210 --- interrupt: c00 at 0x101d0acc <...> ---[ end trace 47b2bf19090bb3d0 ]--- Illegal instructionThe illegal instruction turned out to be 'ldbrx' emitted forBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use ofthe same and implement an alternative approach for older processors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix information leakage in /proc/net/ptypeIn one net namespace, after creating a packet socket without bindingit to a device, users in other net namespaces can observe the new`packet_type` added by this packet socket by reading `/proc/net/ptype`file. This is minor information leakage as packet socket isnamespace aware.Add a net pointer in `packet_type` to keep the net namespace ofof corresponding packet socket. In `ptype_seq_show`, this net pointermust be checked when it is not NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.Mirrors the logic for dcn30. Cue lots of WARNs and somekernel panics without this fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Guard against accessing NULL pt_regs in bpf_get_task_stack()task_pt_regs() can return NULL on powerpc for kernel threads. This isthen used in __bpf_get_stack() to check for user mode, resulting in akernel oops. Guard against this by checking return value oftask_pt_regs() before trying to obtain the call chain.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: lgdt3306a: Add a check against null-pointer-defThe driver should check whether the client provides the platform_data.The following log reveals it:[ 29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40[ 29.610730] Read of size 40 at addr 0000000000000000 by task bash/414[ 29.612820] Call Trace:[ 29.613030] [ 29.613201] dump_stack_lvl+0x56/0x6f[ 29.613496] ? kmemdup+0x30/0x40[ 29.613754] print_report.cold+0x494/0x6b7[ 29.614082] ? kmemdup+0x30/0x40[ 29.614340] kasan_report+0x8a/0x190[ 29.614628] ? kmemdup+0x30/0x40[ 29.614888] kasan_check_range+0x14d/0x1d0[ 29.615213] memcpy+0x20/0x60[ 29.615454] kmemdup+0x30/0x40[ 29.615700] lgdt3306a_probe+0x52/0x310[ 29.616339] i2c_device_probe+0x951/0xa90

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix a memleak when uncloning an skb dst and its metadataWhen uncloning an skb dst and its associated metadata, a newdst+metadata is allocated and later replaces the old one in the skb.This is helpful to have a non-shared dst+metadata attached to a specificskb.The issue is the uncloned dst+metadata is initialized with a refcount of1, which is increased to 2 before attaching it to the skb. Whentun_dst_unclone returns, the dst+metadata is only referenced from asingle place (the skb) while its refcount is 2. Its refcount will neverdrop to 0 (when the skb is consumed), leading to a memory leak.Fix this by removing the call to dst_hold in tun_dst_unclone, as thedst+metadata refcount is already 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure pathip[6]mr_free_table() can only be called under RTNL lock.RTNL: assertion failed at net/core/dev.c (10367)WARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Modules linked in:CPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367Code: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 eeRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfeceRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4R13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000FS: 00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509 ip6mr_free_table net/ipv6/ip6mr.c:389 [inline] ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline] ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline] ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298 ops_init+0xaf/0x470 net/core/net_namespace.c:140 setup_net+0x54f/0xbb0 net/core/net_namespace.c:331 copy_net_ns+0x318/0x760 net/core/net_namespace.c:475 create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110 copy_namespaces+0x391/0x450 kernel/nsproxy.c:178 copy_process+0x2e0c/0x7300 kernel/fork.c:2167 kernel_clone+0xe7/0xab0 kernel/fork.c:2555 __do_sys_clone+0xc8/0x110 kernel/fork.c:2672 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f4ab89f9059Code: Unable to access opcode bytes at RIP 0x7f4ab89f902f.RSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038RAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059RDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000RBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300R10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000R13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: hdmi: Unregister codec device on unbindOn bind we will register the HDMI codec device but we don't unregisterit on unbind, leading to a device leakage. Unregister our device atunbind.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix kernel-infoleak for SCTP socketssyzbot reported a kernel infoleak [1] of 4 bytes.After analysis, it turned out r->idiag_expires is not initializedif inet_sctp_diag_fill() calls inet_diag_msg_common_fill()Make sure to clear idiag_timer/idiag_retrans/idiag_expiresand let inet_diag_msg_sctpasoc_fill() fill them again if needed.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]BUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:154 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 instrument_copy_to_user include/linux/instrumented.h:121 [inline] copyout lib/iov_iter.c:154 [inline] _copy_to_iter+0x6ef/0x25a0 lib/iov_iter.c:668 copy_to_iter include/linux/uio.h:162 [inline] simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519 __skb_datagram_iter+0x2d5/0x11b0 net/core/datagram.c:425 skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533 skb_copy_datagram_msg include/linux/skbuff.h:3696 [inline] netlink_recvmsg+0x669/0x1c80 net/netlink/af_netlink.c:1977 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] __sys_recvfrom+0x795/0xa10 net/socket.c:2097 __do_sys_recvfrom net/socket.c:2115 [inline] __se_sys_recvfrom net/socket.c:2111 [inline] __x64_sys_recvfrom+0x19d/0x210 net/socket.c:2111 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:737 [inline] slab_alloc_node mm/slub.c:3247 [inline] __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4975 kmalloc_reserve net/core/skbuff.c:354 [inline] __alloc_skb+0x545/0xf90 net/core/skbuff.c:426 alloc_skb include/linux/skbuff.h:1158 [inline] netlink_dump+0x3e5/0x16c0 net/netlink/af_netlink.c:2248 __netlink_dump_start+0xcf8/0xe90 net/netlink/af_netlink.c:2373 netlink_dump_start include/linux/netlink.h:254 [inline] inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1341 sock_diag_rcv_msg+0x24a/0x620 netlink_rcv_skb+0x40c/0x7e0 net/netlink/af_netlink.c:2494 sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:277 netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline] netlink_unicast+0x1093/0x1360 net/netlink/af_netlink.c:1343 netlink_sendmsg+0x14d9/0x1720 net/netlink/af_netlink.c:1919 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] sock_write_iter+0x594/0x690 net/socket.c:1061 do_iter_readv_writev+0xa7f/0xc70 do_iter_write+0x52c/0x1500 fs/read_write.c:851 vfs_writev fs/read_write.c:924 [inline] do_writev+0x645/0xe00 fs/read_write.c:967 __do_sys_writev fs/read_write.c:1040 [inline] __se_sys_writev fs/read_write.c:1037 [inline] __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeBytes 68-71 of 2508 are uninitializedMemory access of size 2508 starts at ffff888114f9b000Data copied to user address 00007f7fe09ff2e0CPU: 1 PID: 3478 Comm: syz-executor306 Not tainted 5.17.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix kernel panic when enabling bearerWhen enabling a bearer on a node, a kernel panic is observed:[ 4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]...[ 4.520030] Call Trace:[ 4.520689] [ 4.521236] tipc_link_build_proto_msg+0x375/0x750 [tipc][ 4.522654] tipc_link_build_state_msg+0x48/0xc0 [tipc][ 4.524034] __tipc_node_link_up+0xd7/0x290 [tipc][ 4.525292] tipc_rcv+0x5da/0x730 [tipc][ 4.526346] ? __netif_receive_skb_core+0xb7/0xfc0[ 4.527601] tipc_l2_rcv_msg+0x5e/0x90 [tipc][ 4.528737] __netif_receive_skb_list_core+0x20b/0x260[ 4.530068] netif_receive_skb_list_internal+0x1bf/0x2e0[ 4.531450] ? dev_gro_receive+0x4c2/0x680[ 4.532512] napi_complete_done+0x6f/0x180[ 4.533570] virtnet_poll+0x29c/0x42e [virtio_net]...The node in question is receiving activate messages in anotherthread after changing bearer status to allow message sending/receiving in current thread: thread 1 | thread 2 -------- | -------- |tipc_enable_bearer() | test_and_set_bit_lock() | tipc_bearer_xmit_skb() | | tipc_l2_rcv_msg() | tipc_rcv() | __tipc_node_link_up() | tipc_link_build_state_msg() | tipc_link_build_proto_msg() | tipc_mon_prep() | { | ... | // null-pointer dereference | u16 gen = mon->dom_gen; | ... | } // Not being executed yet | tipc_mon_create() | { | ... | // allocate | mon = kzalloc(); | ... | } |Monitoring pointer in thread 2 is dereferenced before monitoring datais allocated in thread 1. This causes kernel panic.This commit fixes it by allocating the monitoring data before enablingthe bearer to receive messages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not start relocation until in progress drops are doneWe hit a bug with a recovering relocation on mount for one of our filesystems in production. I reproduced this locally by injecting errorsinto snapshot delete with balance running at the same time. Thispresented as an error while looking up an extent item WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680 CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8 RIP: 0010:lookup_inline_extent_backref+0x647/0x680 RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000 RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001 R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000 R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000 FS: 0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0 Call Trace: insert_inline_extent_backref+0x46/0xd0 __btrfs_inc_extent_ref.isra.0+0x5f/0x200 ? btrfs_merge_delayed_refs+0x164/0x190 __btrfs_run_delayed_refs+0x561/0xfa0 ? btrfs_search_slot+0x7b4/0xb30 ? btrfs_update_root+0x1a9/0x2c0 btrfs_run_delayed_refs+0x73/0x1f0 ? btrfs_update_root+0x1a9/0x2c0 btrfs_commit_transaction+0x50/0xa50 ? btrfs_update_reloc_root+0x122/0x220 prepare_to_merge+0x29f/0x320 relocate_block_group+0x2b8/0x550 btrfs_relocate_block_group+0x1a6/0x350 btrfs_relocate_chunk+0x27/0xe0 btrfs_balance+0x777/0xe60 balance_kthread+0x35/0x50 ? btrfs_balance+0xe60/0xe60 kthread+0x16b/0x190 ? set_kthread_struct+0x40/0x40 ret_from_fork+0x22/0x30 Normally snapshot deletion and relocation are excluded from running atthe same time by the fs_info->cleaner_mutex. However if we had apending balance waiting to get the ->cleaner_mutex, and a snapshotdeletion was running, and then the box crashed, we would come up in astate where we have a half deleted snapshot.Again, in the normal case the snapshot deletion needs to complete beforerelocation can start, but in this case relocation could very well startbefore the snapshot deletion completes, as we simply add the root to thedead roots list and wait for the next time the cleaner runs to clean upthe snapshot.Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's thathad a pending drop_progress key. If they do then we know we were in themiddle of the drop operation and set a flag on the fs_info. Thenbalance can wait until this flag is cleared to start up again.If there are DEAD_ROOT's that don't have a drop_progress set then we'resafe to start balance right away as we'll be properly protected by thecleaner_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we're operating on annon-uptodate page. Our overnight tests caught this warning earlier thisweek WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50 CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G W 5.17.0-rc3+ #564 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014 Workqueue: btrfs-cache btrfs_work_helper RIP: 0010:assert_eb_page_uptodate+0x3f/0x50 RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246 RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000 RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0 RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000 R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1 R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000 FS: 0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0 Call Trace: extent_buffer_test_bit+0x3f/0x70 free_space_test_bit+0xa6/0xc0 load_free_space_tree+0x1f6/0x470 caching_thread+0x454/0x630 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? rcu_read_lock_sched_held+0x12/0x60 ? lock_release+0x1f0/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_release+0x1f0/0x2d0 ? finish_task_switch.isra.0+0xf9/0x3a0 process_one_work+0x26d/0x580 ? process_one_work+0x580/0x580 worker_thread+0x55/0x3b0 ? process_one_work+0x580/0x580 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This was partially fixed by c2e39305299f01 ("btrfs: clear extent bufferuptodate when we fail to write it"), however all that fix did was keepus from finding extent buffers after a failed writeout. It didn't keepus from continuing to use a buffer that we already had found.In this case we're searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing. After the switch we can look up an extentbuffer that hasn't been written yet and start processing that blockgroup. Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we're protected by the tree lock to a certain degree here. Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write. However thisisn't necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path->skip_locking set, so thatwon't save us here. We'll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we've "read" a block butit's not marked Uptodate. On read we ClearPageError(), so if we're!Uptodate and !Error we know we didn't do the right thing for readingthe page.Fix this by checking !Uptodate && !Error, this way we will not complainif our buffer gets invalidated while we're using it, and we'll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we're messing with it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: get rid of warning on transaction commit when using flushoncommitWhen using the flushoncommit mount option, during almost every transactioncommit we trigger a warning from __writeback_inodes_sb_nr(): $ cat fs/fs-writeback.c: (...) static void __writeback_inodes_sb_nr(struct super_block *sb, ... { (...) WARN_ON(!rwsem_is_locked(&sb->s_umount)); (...) } (...)The trace produced in dmesg looks like the following: [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3 [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186 [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3 [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...) [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246 [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000 [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50 [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000 [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488 [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460 [947.553621] FS: 0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000 [947.560537] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0 [947.571072] Call Trace: [947.572354] [947.573266] btrfs_commit_transaction+0x1f1/0x998 [947.576785] ? start_transaction+0x3ab/0x44e [947.579867] ? schedule_timeout+0x8a/0xdd [947.582716] transaction_kthread+0xe9/0x156 [947.585721] ? btrfs_cleanup_transaction.isra.0+0x407/0x407 [947.590104] kthread+0x131/0x139 [947.592168] ? set_kthread_struct+0x32/0x32 [947.595174] ret_from_fork+0x22/0x30 [947.597561] [947.598553] ---[ end trace 644721052755541c ]---This is because we started using writeback_inodes_sb() to flush delallocwhen committing a transaction (when using -o flushoncommit), in order toavoid deadlocks with filesystem freeze operations. This change was madeby commit ce8ea7cc6eb313 ("btrfs: don't call btrfs_start_delalloc_rootsin flushoncommit"). After that change we started producing that warning,and every now and then a user reports this since the warning happens toooften, it spams dmesg/syslog, and a user is unsure if this reflects anyproblem that might compromise the filesystem's reliability.We can not just lock the sb->s_umount semaphore before callingwriteback_inodes_sb(), because that would at least deadlock withfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()is called while we are holding that semaphore in write mode, and that cantrigger a transaction commit, resulting in a deadlock. It would alsotrigger the same type of deadlock in the unmount path. Possibly, it couldalso introduce some other locking dependencies that lockdep would report.To fix this call try_to_writeback_inodes_sb() instead ofwriteback_inodes_sb(), because that will try to read lock sb->s_umountand then will only call writeback_inodes_sb() if it was able to lock it.This is fine because the cases where it can't read lock sb->s_umountare during a filesystem unmount or during a filesystem freeze - in thosecases sb->s_umount is write locked and sync_filesystem() is called, whichcalls writeback_inodes_sb(). In other words, in all cases where we can'ttake a read lock on sb->s_umount, writeback is already being triggeredelsewhere.An alternative would be to call btrfs_start_delalloc_roots() with anumber of pages different from LONG_MAX, for example matching the numberof delalloc bytes we currently have, in ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: fix oops caused by irqsoff latency tracerThe trace_hardirqs_{on,off}() require the caller to setup frame pointerproperly. This because these two functions use macro 'CALLER_ADDR1' (aka.__builtin_return_address(1)) to acquire caller info. If the $fp is usedfor other purpose, the code generated this macro (as below) could triggermemory access fault. 0xffffffff8011510e <+80>: ld a1,-16(s0) 0xffffffff80115112 <+84>: ld s2,-8(a1) # <-- paging fault hereThe oops message during booting if compiled with 'irqoff' tracer enabled:[ 0.039615][ T0] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8[ 0.041925][ T0] Oops [#1][ 0.042063][ T0] Modules linked in:[ 0.042864][ T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.17.0-rc1-00233-g9a20c48d1ed2 #29[ 0.043568][ T0] Hardware name: riscv-virtio,qemu (DT)[ 0.044343][ T0] epc : trace_hardirqs_on+0x56/0xe2[ 0.044601][ T0] ra : restore_all+0x12/0x6e[ 0.044721][ T0] epc : ffffffff80126a5c ra : ffffffff80003b94 sp : ffffffff81403db0[ 0.044801][ T0] gp : ffffffff8163acd8 tp : ffffffff81414880 t0 : 0000000000000020[ 0.044882][ T0] t1 : 0098968000000000 t2 : 0000000000000000 s0 : ffffffff81403de0[ 0.044967][ T0] s1 : 0000000000000000 a0 : 0000000000000001 a1 : 0000000000000100[ 0.045046][ T0] a2 : 0000000000000000 a3 : 0000000000000000 a4 : 0000000000000000[ 0.045124][ T0] a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000054494d45[ 0.045210][ T0] s2 : ffffffff80003b94 s3 : ffffffff81a8f1b0 s4 : ffffffff80e27b50[ 0.045289][ T0] s5 : ffffffff81414880 s6 : ffffffff8160fa00 s7 : 00000000800120e8[ 0.045389][ T0] s8 : 0000000080013100 s9 : 000000000000007f s10: 0000000000000000[ 0.045474][ T0] s11: 0000000000000000 t3 : 7fffffffffffffff t4 : 0000000000000000[ 0.045548][ T0] t5 : 0000000000000000 t6 : ffffffff814aa368[ 0.045620][ T0] status: 0000000200000100 badaddr: 00000000000000f8 cause: 000000000000000d[ 0.046402][ T0] [] restore_all+0x12/0x6eThis because the $fp(aka. $s0) register is not used as frame pointer in theassembly entry code. resume_kernel: REG_L s0, TASK_TI_PREEMPT_COUNT(tp) bnez s0, restore_all REG_L s0, TASK_TI_FLAGS(tp) andi s0, s0, _TIF_NEED_RESCHED beqz s0, restore_all call preempt_schedule_irq j restore_allTo fix above issue, here we add one extra level wrapper for functiontrace_hardirqs_{on,off}() so they can be safely called by low level entrycode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memory leak during stateful obj updatestateful objects can be updated from the control plane.The transaction logic allocates a temporary object for this purpose.The ->init function was called for this object, so plain kfree() leaksresources. We must call ->destroy function of the object.nft_obj_destroy does this, but it also decrements the module refcount,but the update path doesn't increment it.To avoid special-casing the update object release, do module_get forthe update case too and release it via nft_obj_destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: mt7621: Add sentinel to quirks tableCurrent driver is missing a sentinel in the struct soc_device_attributearray, which causes an oops when assessed by thesoc_device_match(mt7621_pcie_quirks_match) call.This was only exposed once the CONFIG_SOC_MT7621 mt7621 soc_dev_attrwas fixed to register the SOC as a device, in:commit 7c18b64bba3b ("mips: ralink: mt7621: do not use kzalloc too early")Fix it by adding the required sentinel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix crash when replugging CSR fake controllersIt seems fake CSR 5.0 clones can cause the suspend notifier to beregistered twice causing the following kernel panic:[ 71.986122] Call Trace:[ 71.986124] [ 71.986125] blocking_notifier_chain_register+0x33/0x60[ 71.986130] hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da][ 71.986154] btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477][ 71.986159] ? __pm_runtime_set_status+0x1a9/0x300[ 71.986162] ? ktime_get_mono_fast_ns+0x3e/0x90[ 71.986167] usb_probe_interface+0xe3/0x2b0[ 71.986171] really_probe+0xdb/0x380[ 71.986174] ? pm_runtime_barrier+0x54/0x90[ 71.986177] __driver_probe_device+0x78/0x170[ 71.986180] driver_probe_device+0x1f/0x90[ 71.986183] __device_attach_driver+0x89/0x110[ 71.986186] ? driver_allows_async_probing+0x70/0x70[ 71.986189] bus_for_each_drv+0x8c/0xe0[ 71.986192] __device_attach+0xb2/0x1e0[ 71.986195] bus_probe_device+0x92/0xb0[ 71.986198] device_add+0x422/0x9a0[ 71.986201] ? sysfs_merge_group+0xd4/0x110[ 71.986205] usb_set_configuration+0x57a/0x820[ 71.986208] usb_generic_driver_probe+0x4f/0x70[ 71.986211] usb_probe_device+0x3a/0x110[ 71.986213] really_probe+0xdb/0x380[ 71.986216] ? pm_runtime_barrier+0x54/0x90[ 71.986219] __driver_probe_device+0x78/0x170[ 71.986221] driver_probe_device+0x1f/0x90[ 71.986224] __device_attach_driver+0x89/0x110[ 71.986227] ? driver_allows_async_probing+0x70/0x70[ 71.986230] bus_for_each_drv+0x8c/0xe0[ 71.986232] __device_attach+0xb2/0x1e0[ 71.986235] bus_probe_device+0x92/0xb0[ 71.986237] device_add+0x422/0x9a0[ 71.986239] ? _dev_info+0x7d/0x98[ 71.986242] ? blake2s_update+0x4c/0xc0[ 71.986246] usb_new_device.cold+0x148/0x36d[ 71.986250] hub_event+0xa8a/0x1910[ 71.986255] process_one_work+0x1c4/0x380[ 71.986259] worker_thread+0x51/0x390[ 71.986262] ? rescuer_thread+0x3b0/0x3b0[ 71.986264] kthread+0xdb/0x110[ 71.986266] ? kthread_complete_and_exit+0x20/0x20[ 71.986268] ret_from_fork+0x1f/0x30[ 71.986273] [ 71.986274] ---[ end trace 0000000000000000 ]---[ 71.986284] btusb: probe of 2-1.6:1.0 failed with error -17

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix memory leak in sctp_stream_outq_migrate()When sctp_stream_outq_migrate() is called to release stream out resources,the memory pointed to by prio_head in stream out is not released.The memory leak information is as follows: unreferenced object 0xffff88801fe79f80 (size 64): comm "sctp_repo", pid 7957, jiffies 4294951704 (age 36.480s) hex dump (first 32 bytes): 80 9f e7 1f 80 88 ff ff 80 9f e7 1f 80 88 ff ff ................ 90 9f e7 1f 80 88 ff ff 90 9f e7 1f 80 88 ff ff ................ backtrace: [] kmalloc_trace+0x26/0x60 [] sctp_sched_prio_set+0x4cc/0x770 [] sctp_stream_init_ext+0xd2/0x1b0 [] sctp_sendmsg_to_asoc+0x1614/0x1a30 [] sctp_sendmsg+0xda1/0x1ef0 [] inet_sendmsg+0x9d/0xe0 [] sock_sendmsg+0xd3/0x120 [] __sys_sendto+0x23a/0x340 [] __x64_sys_sendto+0xe1/0x1b0 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: re-fetch skb cb after tipc_msg_validateAs the call trace shows, the original skb was freed in tipc_msg_validate(),and dereferencing the old skb cb would cause an use-after-free crash. BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] Call Trace: tipc_crypto_rcv_complete+0x1835/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc] ... Allocated by task 47078: kmem_cache_alloc_node+0x158/0x4d0 __alloc_skb+0x1c1/0x270 tipc_buf_acquire+0x1e/0xe0 [tipc] tipc_msg_create+0x33/0x1c0 [tipc] tipc_link_build_proto_msg+0x38a/0x2100 [tipc] tipc_link_timeout+0x8b8/0xef0 [tipc] tipc_node_timeout+0x2a1/0x960 [tipc] call_timer_fn+0x2d/0x1c0 ... Freed by task 47078: tipc_msg_validate+0x7b/0x440 [tipc] tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc] tipc_crypto_rcv+0xd32/0x1ec0 [tipc] tipc_rcv+0x744/0x1150 [tipc]This patch fixes it by re-fetching the skb cb from the new allocated skbafter calling tipc_msg_validate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libbpf: Handle size overflow for ringbuf mmapThe maximum size of ringbuf is 2GB on x86-64 host, so 2 * max_entrieswill overflow u32 when mapping producer page and data pages. Onlycasting max_entries to size_t is not enough, because for 32-bitsapplication on 64-bits kernel the size of read-only mmap regionalso could overflow size_t.So fixing it by casting the size of read-only mmap region into a __u64and checking whether or not there will be overflow during mmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix sleep from invalid context bug in btrfs_qgroup_inherit()Syzkaller reported BUG as follows: BUG: sleeping function called from invalid context at include/linux/sched/mm.h:274 Call Trace: dump_stack_lvl+0xcd/0x134 __might_resched.cold+0x222/0x26b kmem_cache_alloc+0x2e7/0x3c0 update_qgroup_limit_item+0xe1/0x390 btrfs_qgroup_inherit+0x147b/0x1ee0 create_subvol+0x4eb/0x1710 btrfs_mksubvol+0xfe5/0x13f0 __btrfs_ioctl_snap_create+0x2b0/0x430 btrfs_ioctl_snap_create_v2+0x25a/0x520 btrfs_ioctl+0x2a1c/0x5ce0 __x64_sys_ioctl+0x193/0x200 do_syscall_64+0x35/0x80Fix this by calling qgroup_dirty() on @dstqgroup, and update limit item inbtrfs_run_qgroups() later outside of the spinlock context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: dev: check return value when calling dev_set_name()If dev_set_name() fails, the dev_name() is null, check the returnvalue of dev_set_name() to avoid the null-ptr-deref.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix panic when growing a memfd_secretWhen one tries to grow an existing memfd_secret with ftruncate, one getsa panic [1]. For example, doing the following reliably induces thepanic: fd = memfd_secret(); ftruncate(fd, 10); ptr = mmap(NULL, 10, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); strcpy(ptr, "123456789"); munmap(ptr, 10); ftruncate(fd, 20);The basic reason for this is, when we grow with ftruncate, we call downinto simple_setattr, and then truncate_inode_pages_range, and eventuallywe try to zero part of the memory. The normal truncation code does thisvia the direct map (i.e., it calls page_address() and hands that tomemset()).For memfd_secret though, we specifically don't map our pages via thedirect map (i.e. we call set_direct_map_invalid_noflush() on everyfault). So the address returned by page_address() isn't useful, andwhen we try to memset() with it we panic.This patch avoids the panic by implementing a custom setattr formemfd_secret, which detects resizes specifically (setting the size forthe first time works just fine, since there are no existing pages to tryto zero), and rejects them with EINVAL.One could argue growing should be supported, but I think that willrequire a significantly more lengthy change. So, I propose a minimalfix for the benefit of stable kernels, and then perhaps to extendmemfd_secret to support growing in a separate patch.[1]: BUG: unable to handle page fault for address: ffffa0a889277028 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD afa01067 P4D afa01067 PUD 83f909067 PMD 83f8bf067 PTE 800ffffef6d88060 Oops: 0002 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 0 PID: 281 Comm: repro Not tainted 5.17.0-dbg-DEV #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:memset_erms+0x9/0x10 Code: c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 f3 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 aa 4c 89 c8 c3 90 49 89 fa 40 0f b6 ce 48 b8 01 01 01 01 01 01 RSP: 0018:ffffb932c09afbf0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffda63c4249dc0 RCX: 0000000000000fd8 RDX: 0000000000000fd8 RSI: 0000000000000000 RDI: ffffa0a889277028 RBP: ffffb932c09afc00 R08: 0000000000001000 R09: ffffa0a889277028 R10: 0000000000020023 R11: 0000000000000000 R12: ffffda63c4249dc0 R13: ffffa0a890d70d98 R14: 0000000000000028 R15: 0000000000000fd8 FS: 00007f7294899580(0000) GS:ffffa0af9bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffa0a889277028 CR3: 0000000107ef6006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? zero_user_segments+0x82/0x190 truncate_inode_partial_folio+0xd4/0x2a0 truncate_inode_pages_range+0x380/0x830 truncate_setsize+0x63/0x80 simple_setattr+0x37/0x60 notify_change+0x3d8/0x4d0 do_sys_ftruncate+0x162/0x1d0 __x64_sys_ftruncate+0x1c/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xae Modules linked in: xhci_pci xhci_hcd virtio_net net_failover failover virtio_blk virtio_balloon uhci_hcd ohci_pci ohci_hcd evdev ehci_pci ehci_hcd 9pnet_virtio 9p netfs 9pnet CR2: ffffa0a889277028[lkp@intel.com: secretmem_iops can be static][axelrasmussen@google.com: return EINVAL]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve overflow the qgroup limitWe use extent_changeset->bytes_changed in qgroup_reserve_data() to recordhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently thebytes_changed is set as "unsigned int", and it will overflow if we try tofallocate a range larger than 4GiB. The result is we reserve less bytesand eventually break the qgroup limit.Unlike regular buffered/direct write, which we use one changeset foreach ordered extent, which can never be larger than 256M. Forfallocate, we use one changeset for the whole range, thus it no longerrespects the 256M per extent limit, and caused the problem.The following example test script reproduces the problem: $ cat qgroup-overflow.sh #!/bin/bash DEV=/dev/sdj MNT=/mnt/sdj mkfs.btrfs -f $DEV mount $DEV $MNT # Set qgroup limit to 2GiB. btrfs quota enable $MNT btrfs qgroup limit 2G $MNT # Try to fallocate a 3GiB file. This should fail. echo echo "Try to fallocate a 3GiB file..." fallocate -l 3G $MNT/3G.file # Try to fallocate a 5GiB file. echo echo "Try to fallocate a 5GiB file..." fallocate -l 5G $MNT/5G.file # See we break the qgroup limit. echo sync btrfs qgroup show -r $MNT umount $MNTWhen running the test: $ ./qgroup-overflow.sh (...) Try to fallocate a 3GiB file... fallocate: fallocate failed: Disk quota exceeded Try to fallocate a 5GiB file... qgroupid rfer excl max_rfer -------- ---- ---- -------- 0/5 5.00GiB 5.00GiB 2.00GiBSince we have no control of how bytes_changed is used, it's better toset it to u64.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: fix a race in rxrpc_exit_net()Current code can lead to the following race:CPU0 CPU1rxrpc_exit_net() rxrpc_peer_keepalive_worker() if (rxnet->live) rxnet->live = false; del_timer_sync(&rxnet->peer_keepalive_timer); timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay); cancel_work_sync(&rxnet->peer_keepalive_work);rxrpc_exit_net() exits while peer_keepalive_timer is still armed,leading to use-after-free.syzbot report was:ODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0WARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505Modules linked in:CPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505Code: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3RSP: 0018:ffffc9000353fb00 EFLAGS: 00010082RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0R13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __debug_check_no_obj_freed lib/debugobjects.c:992 [inline] debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023 kfree+0xd6/0x310 mm/slab.c:3809 ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176 ops_free_list net/core/net_namespace.c:174 [inline] cleanup_net+0x591/0xb00 net/core/net_namespace.c:598 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tls: fix slab-out-of-bounds bug in decrypt_internalThe memory size of tls_ctx->rx.iv for AES128-CCM is 12 setting intls_set_sw_offload(). The return value of crypto_aead_ivsize()for "ccm(aes)" is 16. So memcpy() require 16 bytes from 12 bytesmemory space will trigger slab-out-of-bounds bug as following:==================================================================BUG: KASAN: slab-out-of-bounds in decrypt_internal+0x385/0xc40 [tls]Read of size 16 at addr ffff888114e84e60 by task tls/10911Call Trace: dump_stack_lvl+0x34/0x44 print_report.cold+0x5e/0x5db ? decrypt_internal+0x385/0xc40 [tls] kasan_report+0xab/0x120 ? decrypt_internal+0x385/0xc40 [tls] kasan_check_range+0xf9/0x1e0 memcpy+0x20/0x60 decrypt_internal+0x385/0xc40 [tls] ? tls_get_rec+0x2e0/0x2e0 [tls] ? process_rx_list+0x1a5/0x420 [tls] ? tls_setup_from_iter.constprop.0+0x2e0/0x2e0 [tls] decrypt_skb_update+0x9d/0x400 [tls] tls_sw_recvmsg+0x3c8/0xb50 [tls]Allocated by task 10911: kasan_save_stack+0x1e/0x40 __kasan_kmalloc+0x81/0xa0 tls_set_sw_offload+0x2eb/0xa20 [tls] tls_setsockopt+0x68c/0x700 [tls] __sys_setsockopt+0xfe/0x1b0Replace the crypto_aead_ivsize() with prot->iv_size + prot->salt_sizewhen memcpy() iv value in TLS_1_3_VERSION scenario.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Fix frames flush failure caused by deadlockWe are seeing below warnings:kernel: [25393.301506] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421509] ath11k_pci 0000:01:00.0: failed to flush mgmt transmit queue 0kernel: [25398.421831] ath11k_pci 0000:01:00.0: dropping mgmt frame for vdev 0, is_started 0this means ath11k fails to flush mgmt. frames because wmi_mgmt_tx_workhas no chance to run in 5 seconds.By setting /proc/sys/kernel/hung_task_timeout_secs to 20 and increasingATH11K_FLUSH_TIMEOUT to 50 we get below warnings:kernel: [ 120.763160] INFO: task wpa_supplicant:924 blocked for more than 20 seconds.kernel: [ 120.763169] Not tainted 5.10.90 #12kernel: [ 120.763177] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.kernel: [ 120.763186] task:wpa_supplicant state:D stack: 0 pid: 924 ppid: 1 flags:0x000043a0kernel: [ 120.763201] Call Trace:kernel: [ 120.763214] __schedule+0x785/0x12fakernel: [ 120.763224] ? lockdep_hardirqs_on_prepare+0xe2/0x1bbkernel: [ 120.763242] schedule+0x7e/0xa1kernel: [ 120.763253] schedule_timeout+0x98/0xfekernel: [ 120.763266] ? run_local_timers+0x4a/0x4akernel: [ 120.763291] ath11k_mac_flush_tx_complete+0x197/0x2b1 [ath11k 13c3a9bf37790f4ac8103b3decf7ab4008ac314a]kernel: [ 120.763306] ? init_wait_entry+0x2e/0x2ekernel: [ 120.763343] __ieee80211_flush_queues+0x167/0x21f [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763378] __ieee80211_recalc_idle+0x105/0x125 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763411] ieee80211_recalc_idle+0x14/0x27 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763441] ieee80211_free_chanctx+0x77/0xa2 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763473] __ieee80211_vif_release_channel+0x100/0x131 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763540] ieee80211_vif_release_channel+0x66/0x81 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763572] ieee80211_destroy_auth_data+0xa3/0xe6 [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763612] ieee80211_mgd_deauth+0x178/0x29b [mac80211 335da900954f1c5ea7f1613d92088ce83342042c]kernel: [ 120.763654] cfg80211_mlme_deauth+0x1a8/0x22c [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763697] nl80211_deauthenticate+0xfa/0x123 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763715] genl_rcv_msg+0x392/0x3c2kernel: [ 120.763750] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763782] ? nl80211_associate+0x432/0x432 [cfg80211 8945aa5bc2af5f6972336665d8ad6f9c191ad5be]kernel: [ 120.763802] ? genl_rcv+0x36/0x36kernel: [ 120.763814] netlink_rcv_skb+0x89/0xf7kernel: [ 120.763829] genl_rcv+0x28/0x36kernel: [ 120.763840] netlink_unicast+0x179/0x24bkernel: [ 120.763854] netlink_sendmsg+0x393/0x401kernel: [ 120.763872] sock_sendmsg+0x72/0x76kernel: [ 120.763886] ____sys_sendmsg+0x170/0x1e6kernel: [ 120.763897] ? copy_msghdr_from_user+0x7a/0xa2kernel: [ 120.763914] ___sys_sendmsg+0x95/0xd1kernel: [ 120.763940] __sys_sendmsg+0x85/0xbfkernel: [ 120.763956] do_syscall_64+0x43/0x55kernel: [ 120.763966] entry_SYSCALL_64_after_hwframe+0x44/0xa9kernel: [ 120.763977] RIP: 0033:0x79089f3fcc83kernel: [ 120.763986] RSP: 002b:00007ffe604f0508 EFLAGS: 00000246 ORIG_RAX: 000000000000002ekernel: [ 120.763997] RAX: ffffffffffffffda RBX: 000059b40e987690 RCX: 000079089f3fcc83kernel: [ 120.764006] RDX: 0000000000000000 RSI: 00007ffe604f0558 RDI: 0000000000000009kernel: [ 120.764014] RBP: 00007ffe604f0540 R08: 0000000000000004 R09: 0000000000400000kernel: [ 120.764023] R10: 00007ffe604f0638 R11: 0000000000000246 R12: 000059b40ea04980kernel: [ 120.764032] R13: 00007ffe604---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: svm range restore work deadlock when process exitkfd_process_notifier_release flush svm_range_restore_workwhich calls svm_range_list_lock_and_flush_work to flush deferred_listwork, but if deferred_list work mmput release the last user, it willcall exit_mmap -> notifier_release, it is deadlock with below backtrace.Move flush svm_range_restore_work to kfd_process_wq_release to avoiddeadlock. Then svm_range_restore_work take task->mm ref to avoid mm isgone while validating and mapping ranges to GPU.Workqueue: events svm_range_deferred_list_work [amdgpu]Call Trace: wait_for_completion+0x94/0x100 __flush_work+0x12a/0x1e0 __cancel_work_timer+0x10e/0x190 cancel_delayed_work_sync+0x13/0x20 kfd_process_notifier_release+0x98/0x2a0 [amdgpu] __mmu_notifier_release+0x74/0x1f0 exit_mmap+0x170/0x200 mmput+0x5d/0x130 svm_range_deferred_list_work+0x104/0x230 [amdgpu] process_one_work+0x220/0x3c0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49134 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum: Guard against invalid local portsWhen processing events generated by the device's firmware, the driverprotects itself from events reported for non-existent local ports, butnot for the CPU port (local port 0), which exists, but does not have allthe fields as any local port.This can result in a NULL pointer dereference when trying access'struct mlxsw_sp_port' fields which are not initialized for CPU port.Commit 63b08b1f6834 ("mlxsw: spectrum: Protect driver from buggy firmware")already handled such issue by bailing early when processing a PUDE eventreported for the CPU port.Generalize the approach by moving the check to a common function andmaking use of it in all relevant places.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: preserve skb_end_offset() in skb_unclone_keeptruesize()syzbot found another way to trigger the infamous WARN_ON_ONCE(delta < len)in skb_try_coalesce() [1]I was able to root cause the issue to kfence.When kfence is in action, the following assertion is no longer true:int size = xxxx;void *ptr1 = kmalloc(size, gfp);void *ptr2 = kmalloc(size, gfp);if (ptr1 && ptr2) ASSERT(ksize(ptr1) == ksize(ptr2));We attempted to fix these issues in the blamed commits, but forgotthat TCP was possibly shifting data after skb_unclone_keeptruesize()has been used, notably from tcp_retrans_try_collapse().So we not only need to keep same skb->truesize value,we also need to make sure TCP wont fill new tailroomthat pskb_expand_head() was able to get from aaddr = kmalloc(...) followed by ksize(addr)Split skb_unclone_keeptruesize() into two parts:1) Inline skb_unclone_keeptruesize() for the common case, when skb is not cloned.2) Out of line __skb_unclone_keeptruesize() for the 'slow path'.WARNING: CPU: 1 PID: 6490 at net/core/skbuff.c:5295 skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Modules linked in:CPU: 1 PID: 6490 Comm: syz-executor161 Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:skb_try_coalesce+0x1235/0x1560 net/core/skbuff.c:5295Code: bf 01 00 00 00 0f b7 c0 89 c6 89 44 24 20 e8 62 24 4e fa 8b 44 24 20 83 e8 01 0f 85 e5 f0 ff ff e9 87 f4 ff ff e8 cb 20 4e fa <0f> 0b e9 06 f9 ff ff e8 af b2 95 fa e9 69 f0 ff ff e8 95 b2 95 faRSP: 0018:ffffc900063af268 EFLAGS: 00010293RAX: 0000000000000000 RBX: 00000000ffffffd5 RCX: 0000000000000000RDX: ffff88806fc05700 RSI: ffffffff872abd55 RDI: 0000000000000003RBP: ffff88806e675500 R08: 00000000ffffffd5 R09: 0000000000000000R10: ffffffff872ab659 R11: 0000000000000000 R12: ffff88806dd554e8R13: ffff88806dd9bac0 R14: ffff88806dd9a2c0 R15: 0000000000000155FS: 00007f18014f9700(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002000 CR3: 000000006be7a000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_try_coalesce net/ipv4/tcp_input.c:4651 [inline] tcp_try_coalesce+0x393/0x920 net/ipv4/tcp_input.c:4630 tcp_queue_rcv+0x8a/0x6e0 net/ipv4/tcp_input.c:4914 tcp_data_queue+0x11fd/0x4bb0 net/ipv4/tcp_input.c:5025 tcp_rcv_established+0x81e/0x1ff0 net/ipv4/tcp_input.c:5947 tcp_v4_do_rcv+0x65e/0x980 net/ipv4/tcp_ipv4.c:1719 sk_backlog_rcv include/net/sock.h:1037 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2779 release_sock+0x54/0x1b0 net/core/sock.c:3311 sk_wait_data+0x177/0x450 net/core/sock.c:2821 tcp_recvmsg_locked+0xe28/0x1fd0 net/ipv4/tcp.c:2457 tcp_recvmsg+0x137/0x610 net/ipv4/tcp.c:2572 inet_recvmsg+0x11b/0x5e0 net/ipv4/af_inet.c:850 sock_recvmsg_nosec net/socket.c:948 [inline] sock_recvmsg net/socket.c:966 [inline] sock_recvmsg net/socket.c:962 [inline] ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632 ___sys_recvmsg+0x127/0x200 net/socket.c:2674 __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix memory leak of uid in files registrationWhen there are no files for __io_sqe_files_scm() to process in therange, it'll free everything and return. However, it forgets to put uid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix call timer start racing with call destructionThe rxrpc_call struct has a timer used to handle various timed eventsrelating to a call. This timer can get started from the packet inputroutines that are run in softirq mode with just the RCU read lock held.Unfortunately, because only the RCU read lock is held - and neither ref orother lock is taken - the call can start getting destroyed at the same timea packet comes in addressed to that call. This causes the timer - whichwas already stopped - to get restarted. Later, the timer dispatch code maythen oops if the timer got deallocated first.Fix this by trying to take a ref on the rxrpc_call struct and, ifsuccessful, passing that ref along to the timer. If the timer was alreadyrunning, the ref is discarded.The timer completion routine can then pass the ref along to the call's workitem when it queues it. If the timer or work item where alreadyqueued/running, the extra ref is discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: mediatek: Fix error handling in mt8183_da7219_max98357_dev_probeThe device_node pointer is returned by of_parse_phandle() with refcountincremented. We should use of_node_put() on it when done.This function only calls of_node_put() in the regular path.And it will cause refcount leak in error paths.Fix this by calling of_node_put() in error handling too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not double complete bio on errors during compressed readsI hit some weird panics while fixing up the error handling frombtrfs_lookup_bio_sums(). Turns out the compression path will completethe bio we use if we set up any of the compression bios and then returnan error, and then btrfs_submit_data_bio() will also call bio_endio() onthe bio.Fix this by making btrfs_submit_compressed_read() responsible forcalling bio_endio() on the bio if there are any errors. Currently itwas only doing it if we created the compression bios, otherwise it wasdepending on btrfs_submit_data_bio() to do the right thing. Thiscreates the above problem, so fix up btrfs_submit_compressed_read() toalways call bio_endio() in case of an error, and then simply return frombtrfs_submit_data_bio() if we had to callbtrfs_submit_compressed_read().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49168 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not clean up repair bio if submit failsThe submit helper will always run bio_endio() on the bio if it fails tosubmit, so cleaning up the bio just leads to a variety of use-after-freeand NULL pointer dereference bugs because we race with the endiofunction that is cleaning up the bio. Instead just return BLK_STS_OK asthe repair function has to continue to process the rest of the pages,and the endio for the repair bio will do the appropriate cleanup for thepage that it was given.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memstick/mspro_block: fix handling of read-only devicesUse set_disk_ro to propagate the read-only state to the block layerinstead of checking for it in ->open and leaking a reference in caseof a read-only device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/resource: fix kfree() of bootmem memory againSince commit ebff7d8f270d ("mem hotunplug: fix kfree() of bootmemmemory"), we could get a resource allocated during boot viaalloc_resource(). And it's required to release the resource usingfree_resource(). Howerver, many people use kfree directly which willresult in kernel BUG. In order to fix this without fixing every callsite, just leak a couple of bytes in such corner case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mxser: fix xmit_buf leak in activate when LSR == 0xffWhen LSR is 0xff in ->activate() (rather unlike), we return an error.Provided ->shutdown() is not called when ->activate() fails, nothingactually frees the buffer in this case.Fix this by properly freeing the buffer in a designated label. We jumpthere also from the "!info->type" if now too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix more uncharged while msg has more_dataIn tcp_bpf_send_verdict(), if msg has more data aftertcp_bpf_sendmsg_redir():tcp_bpf_send_verdict() tosend = msg->sg.size //msg->sg.size = 22220 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(22220) sk->sk_forward_alloc tcp_bpf_sendmsg_redir() //after tcp_bpf_sendmsg_redir, msg->sg.size=11000 goto more_data; tosend = msg->sg.size //msg->sg.size = 11000 case __SK_REDIRECT: sk_msg_return() //uncharged msg->sg.size(11000) to sk->sk_forward_allocThe msg->sg.size(11000) has been uncharged twice, to fix we can charge theremaining msg->sg.size before goto more data.This issue can cause the following info:WARNING: CPU: 0 PID: 9860 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 ? vfs_write+0x237/0x290 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix double uncharge the mem of sk_msgIf tcp_bpf_sendmsg is running during a tear down operation, psock may befreed.tcp_bpf_sendmsg() tcp_bpf_send_verdict() sk_msg_return() tcp_bpf_sendmsg_redir() unlikely(!psock)) sk_msg_free()The mem of msg has been uncharged in tcp_bpf_send_verdict() bysk_msg_return(), and would be uncharged by sk_msg_free() again. When psockis null, we can simply returning an error code, this would then triggerthe sk_msg_free_nocharge in the error path of __SK_REDIRECT and would havethe side effect of throwing an error up to user space. This would be aslight change in behavior from user side but would look the same as anerror if the redirect on the socket threw an error.This issue can cause the following info:WARNING: CPU: 0 PID: 2136 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in sk_psock_queue_msgIf tcp_bpf_sendmsg is running during a tear down operation we may enqueuedata on the ingress msg queue while tear down is trying to free it. sk1 (redirect sk2) sk2 ------------------- ---------------tcp_bpf_sendmsg() tcp_bpf_send_verdict() tcp_bpf_sendmsg_redir() bpf_tcp_ingress() sock_map_close() lock_sock() lock_sock() ... blocking sk_psock_stop sk_psock_clear_state(psock, SK_PSOCK_TX_ENABLED); release_sock(sk); lock_sock() sk_mem_charge() get_page() sk_psock_queue_msg() sk_psock_test_state(psock, SK_PSOCK_TX_ENABLED); drop_sk_msg() release_sock()While drop_sk_msg(), the msg has charged memory form sk by sk_mem_chargeand has sg pages need to put. To fix we use sk_msg_free() and then kfee()msg.This issue can cause the following info:WARNING: CPU: 0 PID: 9202 at net/core/stream.c:205 sk_stream_kill_queues+0xc8/0xe0Call Trace: inet_csk_destroy_sock+0x55/0x110 tcp_rcv_state_process+0xe5f/0xe90 ? sk_filter_trim_cap+0x10d/0x230 ? tcp_v4_do_rcv+0x161/0x250 tcp_v4_do_rcv+0x161/0x250 tcp_v4_rcv+0xc3a/0xce0 ip_protocol_deliver_rcu+0x3d/0x230 ip_local_deliver_finish+0x54/0x60 ip_local_deliver+0xfd/0x110 ? ip_protocol_deliver_rcu+0x230/0x230 ip_rcv+0xd6/0x100 ? ip_local_deliver+0x110/0x110 __netif_receive_skb_one_core+0x85/0xa0 process_backlog+0xa4/0x160 __napi_poll+0x29/0x1b0 net_rx_action+0x287/0x300 __do_softirq+0xff/0x2fc do_softirq+0x79/0x90 WARNING: CPU: 0 PID: 531 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x175/0x1b0Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 ? process_one_work+0x3c0/0x3c0 worker_thread+0x30/0x350 ? process_one_work+0x3c0/0x3c0 kthread+0xe6/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49209 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is fullIf tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partialmemory has been alloced by sk_msg_alloc(), that is, msg_tx->sg.size isgreater than osize after sk_msg_alloc(), memleak occurs. To fix we usesk_msg_trim() to release the allocated memory, then goto wait for memory.Other call paths of sk_msg_alloc() have the similar issue, such astls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),as Cong Wang suggested.This issue can cause the following info:WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0Call Trace: inet_csk_destroy_sock+0x55/0x110 __tcp_close+0x279/0x470 tcp_close+0x1f/0x60 inet_release+0x3f/0x80 __sock_release+0x3d/0xb0 sock_close+0x11/0x20 __fput+0x92/0x250 task_work_run+0x6a/0xa0 do_exit+0x33b/0xb60 do_group_exit+0x2f/0xa0 get_signal+0xb6/0x950 arch_do_signal_or_restart+0xac/0x2a0 exit_to_user_mode_prepare+0xa9/0x200 syscall_exit_to_user_mode+0x12/0x30 do_syscall_64+0x46/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260Call Trace: __sk_destruct+0x24/0x1f0 sk_psock_destroy+0x19b/0x1c0 process_one_work+0x1b3/0x3c0 kthread+0xe6/0x110 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race at socket teardownFix a race in the xsk socket teardown code that can lead to a NULL pointerdereference splat. The current xsk unbind code in xsk_unbind_dev() starts bysetting xs->state to XSK_UNBOUND, sets xs->dev to NULL and then waits for anyNAPI processing to terminate using synchronize_net(). After that, the releasecode starts to tear down the socket state and free allocated memory. BUG: kernel NULL pointer dereference, address: 00000000000000c0 PGD 8000000932469067 P4D 8000000932469067 PUD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 25 PID: 69132 Comm: grpcpp_sync_ser Tainted: G I 5.16.0+ #2 Hardware name: Dell Inc. PowerEdge R730/0599V5, BIOS 1.2.10 03/09/2015 RIP: 0010:__xsk_sendmsg+0x2c/0x690 [...] RSP: 0018:ffffa2348bd13d50 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000040 RCX: ffff8d5fc632d258 RDX: 0000000000400000 RSI: ffffa2348bd13e10 RDI: ffff8d5fc5489800 RBP: ffffa2348bd13db0 R08: 0000000000000000 R09: 00007ffffffff000 R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d5fc5489800 R13: ffff8d5fcb0f5140 R14: ffff8d5fcb0f5140 R15: 0000000000000000 FS: 00007f991cff9400(0000) GS:ffff8d6f1f700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000c0 CR3: 0000000114888005 CR4: 00000000001706e0 Call Trace: ? aa_sk_perm+0x43/0x1b0 xsk_sendmsg+0xf0/0x110 sock_sendmsg+0x65/0x70 __sys_sendto+0x113/0x190 ? debug_smp_processor_id+0x17/0x20 ? fpregs_assert_state_consistent+0x23/0x50 ? exit_to_user_mode_prepare+0xa5/0x1d0 __x64_sys_sendto+0x29/0x30 do_syscall_64+0x3b/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xaeThere are two problems with the current code. First, setting xs->dev to NULLbefore waiting for all users to stop using the socket is not correct. Theentry to the data plane functions xsk_poll(), xsk_sendmsg(), and xsk_recvmsg()are all guarded by a test that xs->state is in the state XSK_BOUND and if not,it returns right away. But one process might have passed this test but stillhave not gotten to the point in which it uses xs->dev in the code. In thisinterim, a second process executing xsk_unbind_dev() might have set xs->dev toNULL which will lead to a crash for the first process. The solution here isjust to get rid of this NULL assignment since it is not used anymore. Beforecommit 42fddcc7c64b ("xsk: use state member for socket synchronization"),xs->dev was the gatekeeper to admit processes into the data plane functions,but it was replaced with the state variable xs->state in the aforementionedcommit.The second problem is that synchronize_net() does not wait for any process inxsk_poll(), xsk_sendmsg(), or xsk_recvmsg() to complete, which means that thestate they rely on might be cleaned up prematurely. This can happen when thenotifier gets called (at driver unload for example) as it uses xsk_unbind_dev().Solve this by extending the RCU critical region from just the ndo_xsk_wakeupto the whole functions mentioned above, so that both the test of xs->state ==XSK_BOUND and the last use of any member of xs is covered by the RCU criticalsection. This will guarantee that when synchronize_net() completes, there willbe no processes left executing xsk_poll(), xsk_sendmsg(), or xsk_recvmsg() andstate can be cleaned up safely. Note that we need to drop the RCU lock for theskb xmit path as it uses functions that might sleep. Due to this, we have toretest the xs->state after we grab the mutex that protects the skb xmit codefrom, among a number of things, an xsk_unbind_dev() being executed from thenotifier at the same time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: fix memory leak during D3hot to D0 transitionIf 'vfio_pci_core_device::needs_pm_restore' is set (PCI device doesnot have No_Soft_Reset bit set in its PMCSR config register), thenthe current PCI state will be saved locally in'vfio_pci_core_device::pm_save' during D0->D3hot transition and samewill be restored back during D3hot->D0 transition.For saving the PCI state locally, pci_store_saved_state() is beingused and the pci_load_and_free_saved_state() will free the allocatedmemory.But for reset related IOCTLs, vfio driver calls PCI reset-relatedAPI's which will internally change the PCI power state back to D0. So,when the guest resumes, then it will get the current state as D0 and itwill skip the call to vfio_pci_set_power_state() for changing thepower state to D0 explicitly. In this case, the memory pointed by'pm_save' will never be freed. In a malicious sequence, the state changingto D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can berun in a loop and it can cause an OOM situation.This patch frees the earlier allocated memory first before overwriting'pm_save' to prevent the mentioned memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dax: make sure inodes are flushed before destroy cacheA bug can be triggered by following command$ modprobe nd_pmem && modprobe -r nd_pmem[ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()[ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)[ 10.062433] Call Trace:[ 10.062673] dump_stack_lvl+0x34/0x44[ 10.062865] slab_err+0x90/0xd0[ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0[ 10.063848] kmem_cache_destroy+0x4a/0x110[ 10.064058] __x64_sys_delete_module+0x265/0x300This is caused by dax_fs_exit() not flushing inodes before destroy cache.To fix this issue, call rcu_barrier() before destroy cache.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl/port: Hold port reference until decoder releaseKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free incxl_decoder_release() where it goes to reference its parent, a cxl_port,to free its id back to port->decoder_ida. BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core] Read of size 8 at addr ffff888119270908 by task kworker/35:2/379 CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Workqueue: events kobject_delayed_cleanup Call Trace: dump_stack_lvl+0x59/0x73 print_address_description.constprop.0+0x1f/0x150 ? to_cxl_port+0x18/0x90 [cxl_core] kasan_report.cold+0x83/0xdf ? to_cxl_port+0x18/0x90 [cxl_core] to_cxl_port+0x18/0x90 [cxl_core] cxl_decoder_release+0x2a/0x60 [cxl_core] device_release+0x5f/0x100 kobject_cleanup+0x80/0x1c0The device core only guarantees parent lifetime until all children areunregistered. If a child needs a parent to complete its ->release()callback that child needs to hold a reference to extend the lifetime ofthe parent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49229 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: unregister virtual clocks when unregistering physical clock.When unregistering a physical clock which has some virtual clocks,unregister the virtual clocks with it.This fixes the following oops, which can be triggered by unloadinga driver providing a PTP clock when it has enabled virtual clocks:BUG: unable to handle page fault for address: ffffffffc04fc4d8Oops: 0000 [#1] PREEMPT SMP NOPTIRIP: 0010:ptp_vclock_read+0x31/0xb0Call Trace: timecounter_read+0xf/0x50 ptp_vclock_refresh+0x2c/0x50 ? ptp_clock_release+0x40/0x40 ptp_aux_kworker+0x17/0x30 kthread_worker_fn+0x9b/0x240 ? kthread_should_park+0x30/0x30 kthread+0xe2/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49234 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Avoid cross-chip syncing of VLAN filteringChanges to VLAN filtering are not applicable to cross-chipnotifications.On a system like this:.-----. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-' '-1-2-' '-1-2-'Before this change, upon sw1p1 leaving a bridge, a call todsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.In this scenario:.---------. .-----. .-----.| sw1 +---+ sw2 +---+ sw3 |'-1-2-3-4-' '-1-2-' '-1-2-'When sw1p4 would leave a bridge, dsa_port_vlan_filtering would becalled for sw2 and sw3 with a non-existing port - leading to arrayout-of-bounds accesses and crashes on mv88e6xxx.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49282 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: quota: fix loop condition at f2fs_quota_sync()cnt should be passed to sb_has_quota_active() instead of type to checkactive quota properly.Moreover, when the type is -1, the compiler with enough inline knowledgecan discard sb_has_quota_active() check altogether, causing a NULL pointerdereference at the following inode_lock(dqopt->files[cnt]):[ 2.796010] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 2.796024] Mem abort info:[ 2.796025] ESR = 0x96000005[ 2.796028] EC = 0x25: DABT (current EL), IL = 32 bits[ 2.796029] SET = 0, FnV = 0[ 2.796031] EA = 0, S1PTW = 0[ 2.796032] Data abort info:[ 2.796034] ISV = 0, ISS = 0x00000005[ 2.796035] CM = 0, WnR = 0[ 2.796046] user pgtable: 4k pages, 39-bit VAs, pgdp=00000003370d1000[ 2.796048] [00000000000000a0] pgd=0000000000000000, pud=0000000000000000[ 2.796051] Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 2.796056] CPU: 7 PID: 640 Comm: f2fs_ckpt-259:7 Tainted: G S 5.4.179-arter97-r8-64666-g2f16e087f9d8 #1[ 2.796057] Hardware name: Qualcomm Technologies, Inc. Lahaina MTP lemonadep (DT)[ 2.796059] pstate: 80c00005 (Nzcv daif +PAN +UAO)[ 2.796065] pc : down_write+0x28/0x70[ 2.796070] lr : f2fs_quota_sync+0x100/0x294[ 2.796071] sp : ffffffa3f48ffc30[ 2.796073] x29: ffffffa3f48ffc30 x28: 0000000000000000[ 2.796075] x27: ffffffa3f6d718b8 x26: ffffffa415fe9d80[ 2.796077] x25: ffffffa3f7290048 x24: 0000000000000001[ 2.796078] x23: 0000000000000000 x22: ffffffa3f7290000[ 2.796080] x21: ffffffa3f72904a0 x20: ffffffa3f7290110[ 2.796081] x19: ffffffa3f77a9800 x18: ffffffc020aae038[ 2.796083] x17: ffffffa40e38e040 x16: ffffffa40e38e6d0[ 2.796085] x15: ffffffa40e38e6cc x14: ffffffa40e38e6d0[ 2.796086] x13: 00000000000004f6 x12: 00162c44ff493000[ 2.796088] x11: 0000000000000400 x10: ffffffa40e38c948[ 2.796090] x9 : 0000000000000000 x8 : 00000000000000a0[ 2.796091] x7 : 0000000000000000 x6 : 0000d1060f00002a[ 2.796093] x5 : ffffffa3f48ff718 x4 : 000000000000000d[ 2.796094] x3 : 00000000060c0000 x2 : 0000000000000001[ 2.796096] x1 : 0000000000000000 x0 : 00000000000000a0[ 2.796098] Call trace:[ 2.796100] down_write+0x28/0x70[ 2.796102] f2fs_quota_sync+0x100/0x294[ 2.796104] block_operations+0x120/0x204[ 2.796106] f2fs_write_checkpoint+0x11c/0x520[ 2.796107] __checkpoint_and_complete_reqs+0x7c/0xd34[ 2.796109] issue_checkpoint_thread+0x6c/0xb8[ 2.796112] kthread+0x138/0x414[ 2.796114] ret_from_fork+0x10/0x18[ 2.796117] Code: aa0803e0 aa1f03e1 52800022 aa0103e9 (c8e97d02)[ 2.796120] ---[ end trace 96e942e8eb6a0b53 ]---[ 2.800116] Kernel panic - not syncing: Fatal exception[ 2.800120] SMP: stopping secondary CPUs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add accessors to read/set tp->snd_cwndWe had various bugs over the years with codebreaking the assumption that tp->snd_cwnd is greaterthan zero.Lately, syzbot reported the WARN_ON_ONCE(!tp->prior_cwnd) addedin commit 8b8a321ff72c ("tcp: fix zero cwnd in tcp_cwnd_reduction")can trigger, and without a repro we would have to spendconsiderable time finding the bug.Instead of complaining too late, we want to catch whereand when tp->snd_cwnd is set to an illegal value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix tcp_mtup_probe_success vs wrong snd_cwndsyzbot got a new report [1] finally pointing to a very old bug,added in initial support for MTU probing.tcp_mtu_probe() has checks about starting an MTU probe iftcp_snd_cwnd(tp) >= 11.But nothing prevents tcp_snd_cwnd(tp) to be reduced laterand before the MTU probe succeeds.This bug would lead to potential zero-divides.Debugging added in commit 40570375356c ("tcp: add accessorsto read/set tp->snd_cwnd") has paid off :)While we are at it, address potential overflows in this code.[1]WARNING: CPU: 1 PID: 14132 at include/net/tcp.h:1219 tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Modules linked in:CPU: 1 PID: 14132 Comm: syz-executor.2 Not tainted 5.18.0-syzkaller-07857-gbabf0bb978e3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:tcp_snd_cwnd_set include/net/tcp.h:1219 [inline]RIP: 0010:tcp_mtup_probe_success+0x366/0x570 net/ipv4/tcp_input.c:2712Code: 74 08 48 89 ef e8 da 80 17 f9 48 8b 45 00 65 48 ff 80 80 03 00 00 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 e8 aa b0 c5 f8 <0f> 0b e9 16 fe ff ff 48 8b 4c 24 08 80 e1 07 38 c1 0f 8c c7 fc ffRSP: 0018:ffffc900079e70f8 EFLAGS: 00010287RAX: ffffffff88c0f7f6 RBX: ffff8880756e7a80 RCX: 0000000000040000RDX: ffffc9000c6c4000 RSI: 0000000000031f9e RDI: 0000000000031f9fRBP: 0000000000000000 R08: ffffffff88c0f606 R09: ffffc900079e7520R10: ffffed101011226d R11: 1ffff1101011226c R12: 1ffff1100eadcf50R13: ffff8880756e72c0 R14: 1ffff1100eadcf89 R15: dffffc0000000000FS: 00007f643236e700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1ab3f1e2a0 CR3: 0000000064fe7000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_clean_rtx_queue+0x223a/0x2da0 net/ipv4/tcp_input.c:3356 tcp_ack+0x1962/0x3c90 net/ipv4/tcp_input.c:3861 tcp_rcv_established+0x7c8/0x1ac0 net/ipv4/tcp_input.c:5973 tcp_v6_do_rcv+0x57b/0x1210 net/ipv6/tcp_ipv6.c:1476 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x1d8/0x4c0 net/core/sock.c:2849 release_sock+0x5d/0x1c0 net/core/sock.c:3404 sk_stream_wait_memory+0x700/0xdc0 net/core/stream.c:145 tcp_sendmsg_locked+0x111d/0x3fc0 net/ipv4/tcp.c:1410 tcp_sendmsg+0x2c/0x40 net/ipv4/tcp.c:1448 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x439/0x5c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0xda/0xf0 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f6431289109Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f643236e168 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f643139c100 RCX: 00007f6431289109RDX: 00000000d0d0c2ac RSI: 0000000020000080 RDI: 000000000000000aRBP: 00007f64312e308d R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000000R13: 00007fff372533af R14: 00007f643236e300 R15: 0000000000022000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49333 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: E-Switch, pair only capable devicesOFFLOADS paring using devcom is possible only on devicesthat support LAG. Filter based on lag capabilities.This fixes an issue where mlx5_get_next_phys_dev() wascalled without holding the interface lock.This issue was found when commitbc4c2f2e0179 ("net/mlx5: Lag, filter non compatible devices")added an assert that verifies the interface lock is held.WARNING: CPU: 9 PID: 1706 at drivers/net/ethernet/mellanox/mlx5/core/dev.c:642 mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Modules linked in: mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_umad ib_ipoib ib_cm ib_uverbs ib_core overlay fuse [last unloaded: mlx5_core]CPU: 9 PID: 1706 Comm: devlink Not tainted 5.18.0-rc7+ #11Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:mlx5_get_next_phys_dev+0xd2/0x100 [mlx5_core]Code: 02 00 75 48 48 8b 85 80 04 00 00 5d c3 31 c0 5d c3 be ff ff ff ff 48 c7 c7 08 41 5b a0 e8 36 87 28 e3 85 c0 0f 85 6f ff ff ff <0f> 0b e9 68 ff ff ff 48 c7 c7 0c 91 cc 84 e8 cb 36 6f e1 e9 4d ffRSP: 0018:ffff88811bf47458 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88811b398000 RCX: 0000000000000001RDX: 0000000080000000 RSI: ffffffffa05b4108 RDI: ffff88812daaaa78RBP: ffff88812d050380 R08: 0000000000000001 R09: ffff88811d6b3437R10: 0000000000000001 R11: 00000000fddd3581 R12: ffff88815238c000R13: ffff88812d050380 R14: ffff8881018aa7e0 R15: ffff88811d6b3428FS: 00007fc82e18ae80(0000) GS:ffff88842e080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9630d1b421 CR3: 0000000149802004 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: mlx5_esw_offloads_devcom_event+0x99/0x3b0 [mlx5_core] mlx5_devcom_send_event+0x167/0x1d0 [mlx5_core] esw_offloads_enable+0x1153/0x1500 [mlx5_core] ? mlx5_esw_offloads_controller_valid+0x170/0x170 [mlx5_core] ? wait_for_completion_io_timeout+0x20/0x20 ? mlx5_rescan_drivers_locked+0x318/0x810 [mlx5_core] mlx5_eswitch_enable_locked+0x586/0xc50 [mlx5_core] ? mlx5_eswitch_disable_pf_vf_vports+0x1d0/0x1d0 [mlx5_core] ? mlx5_esw_try_lock+0x1b/0xb0 [mlx5_core] ? mlx5_eswitch_enable+0x270/0x270 [mlx5_core] ? __debugfs_create_file+0x260/0x3e0 mlx5_devlink_eswitch_mode_set+0x27e/0x870 [mlx5_core] ? mutex_lock_io_nested+0x12c0/0x12c0 ? esw_offloads_disable+0x250/0x250 [mlx5_core] ? devlink_nl_cmd_trap_get_dumpit+0x470/0x470 ? rcu_read_lock_sched_held+0x3f/0x70 devlink_nl_cmd_eswitch_set_doit+0x217/0x620

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49340 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip_gre: test csum_start instead of transport headerGRE with TUNNEL_CSUM will apply local checksum offload onCHECKSUM_PARTIAL packets.ipgre_xmit must validate csum_start after an optional skb_pull,else lco_csum may trigger an overflow. The original check was if (csum && skb_checksum_start(skb) < skb->data) return -EINVAL;This had false positives when skb_checksum_start is undefined:when ip_summed is not CHECKSUM_PARTIAL. A discussed refinementwas straightforward if (csum && skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start(skb) < skb->data) return -EINVAL;But was eventually revised more thoroughly:- restrict the check to the only branch where needed, in an uncommon GRE path that uses header_ops and calls skb_pull.- test skb_transport_header, which is set along with csum_start in skb_partial_csum_set in the normal header_ops datapath.Turns out skbs can arrive in this branch without the transportheader set, e.g., through BPF redirection.Revise the check back to check csum_start directly, and only ifCHECKSUM_PARTIAL. Do leave the check in the updated location.Check field regardless of whether TUNNEL_CSUM is configured.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix a data-race in unix_dgram_peer_wake_me().unix_dgram_poll() calls unix_dgram_peer_wake_me() without `other`'slock held and check if its receive queue is full. Here we need touse unix_recvq_full_lockless() instead of unix_recvq_full(), otherwiseKCSAN will report a data-race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49358 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: memleak flow rule from commit pathAbort path release flow rule object, however, commit path does not.Update code to destroy these objects before releasing the transaction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Job should reference MMU not file_privFor a while now it's been allowed for a MMU context to outlive it'scorresponding panfrost_priv, however the job structure still referencespanfrost_priv to get hold of the MMU context. If panfrost_priv has beenfreed this is a use-after-free which I've been able to trigger resultingin a splat.To fix this, drop the reference to panfrost_priv in the job structureand add a direct reference to the MMU structure which is what's actuallyneeded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_rtx_synack() can be called from process contextLaurent reported the enclosed report [1]This bug triggers with following coditions:0) Kernel built with CONFIG_DEBUG_PREEMPT=y1) A new passive FastOpen TCP socket is created. This FO socket waits for an ACK coming from client to be a complete ESTABLISHED one.2) A socket operation on this socket goes through lock_sock() release_sock() dance.3) While the socket is owned by the user in step 2), a retransmit of the SYN is received and stored in socket backlog.4) At release_sock() time, the socket backlog is processed while in process context.5) A SYNACK packet is cooked in response of the SYN retransmit.6) -> tcp_rtx_synack() is called in process context.Before blamed commit, tcp_rtx_synack() was always called from BH handler,from a timer handler.Fix this by using TCP_INC_STATS() & NET_INC_STATS()which do not assume caller is in non preemptible context.[1]BUG: using __this_cpu_add() in preemptible [00000000] code: epollpep/2180caller is tcp_rtx_synack.part.0+0x36/0xc0CPU: 10 PID: 2180 Comm: epollpep Tainted: G OE 5.16.0-0.bpo.4-amd64 #1 Debian 5.16.12-1~bpo11+1Hardware name: Supermicro SYS-5039MC-H8TRF/X11SCD-F, BIOS 1.7 11/23/2021Call Trace: dump_stack_lvl+0x48/0x5e check_preemption_disabled+0xde/0xe0 tcp_rtx_synack.part.0+0x36/0xc0 tcp_rtx_synack+0x8d/0xa0 ? kmem_cache_alloc+0x2e0/0x3e0 ? apparmor_file_alloc_security+0x3b/0x1f0 inet_rtx_syn_ack+0x16/0x30 tcp_check_req+0x367/0x610 tcp_rcv_state_process+0x91/0xf60 ? get_nohz_timer_target+0x18/0x1a0 ? lock_timer_base+0x61/0x80 ? preempt_count_add+0x68/0xa0 tcp_v4_do_rcv+0xbd/0x270 __release_sock+0x6d/0xb0 release_sock+0x2b/0x90 sock_setsockopt+0x138/0x1140 ? __sys_getsockname+0x7e/0xc0 ? aa_sk_perm+0x3e/0x1a0 __sys_setsockopt+0x198/0x1e0 __x64_sys_setsockopt+0x21/0x30 do_syscall_64+0x38/0xc0 entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49374 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: check attribute length for bearer namesyzbot reported uninit-value:=====================================================BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]BUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725 string_nocheck lib/vsprintf.c:644 [inline] string+0x4f9/0x6f0 lib/vsprintf.c:725 vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806 vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158 vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256 vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283 vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50 _printk+0x18d/0x1cf kernel/printk/printk.c:2293 tipc_enable_bearer net/tipc/bearer.c:371 [inline] __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033 tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.- Do not use 'illegal name' in printing message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: ubi_create_volume: Fix use-after-free when volume creation failedThere is an use-after-free problem for 'eba_tbl' in ubi_create_volume()'serror handling path: ubi_eba_replace_table(vol, eba_tbl) vol->eba_tbl = tblout_mapping: ubi_eba_destroy_table(eba_tbl) // Free 'eba_tbl'out_unlock: put_device(&vol->dev) vol_release kfree(tbl->entries) // UAFFix it by removing redundant 'eba_tbl' releasing.Fetch a reproducer in [Link].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:macsec: fix UAF bug for real_devCreate a new macsec device but not get reference to real_dev. That cannot ensure that real_dev is freed after macsec. That will trigger theUAF bug for real_dev as following:==================================================================BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662Call Trace: ... macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662 dev_get_iflink+0x73/0xe0 net/core/dev.c:637 default_operstate net/core/link_watch.c:42 [inline] rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54 linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161Allocated by task 22209: ... alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549 rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235 veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748Freed by task 8: ... kfree+0xd6/0x4d0 mm/slub.c:4552 kvfree+0x42/0x50 mm/util.c:615 device_release+0x9f/0x240 drivers/base/core.c:2229 kobject_cleanup lib/kobject.c:673 [inline] kobject_release lib/kobject.c:704 [inline] kref_put include/linux/kref.h:65 [inline] kobject_put+0x1c8/0x540 lib/kobject.c:721 netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), wecan add dev_hold_track() in macsec_dev_init() and dev_put_track() inmacsec_free_netdev() to fix the problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: Fix out-of-bounds read in LDT setupsyscall_stub_data() expects the data_count parameter to be the number oflongs, not bytes. ================================================================== BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0 Read of size 128 at addr 000000006411f6f0 by task swapper/1 CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18 Call Trace: show_stack.cold+0x166/0x2a7 __dump_stack+0x3a/0x43 dump_stack_lvl+0x1f/0x27 print_report.cold+0xdb/0xf81 kasan_report+0x119/0x1f0 kasan_check_range+0x3a3/0x440 memcpy+0x52/0x140 syscall_stub_data+0x70/0xe0 write_ldt_entry+0xac/0x190 init_new_ldt+0x515/0x960 init_new_context+0x2c4/0x4d0 mm_init.constprop.0+0x5ed/0x760 mm_alloc+0x118/0x170 0x60033f48 do_one_initcall+0x1d7/0x860 0x60003e7b kernel_init+0x6e/0x3d4 new_thread_handler+0x1e7/0x2c0 The buggy address belongs to stack of task swapper/1 and is located at offset 64 in frame: init_new_ldt+0x0/0x960 This frame has 2 objects: [32, 40) 'addr' [64, 80) 'desc' ==================================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: annotate races around sk->sk_bound_dev_ifUDP sendmsg() is lockless, and reads sk->sk_bound_dev_if whilethis field can be changed by another thread.Adds minimal annotations to avoid KCSAN splats for UDP.Following patches will add more annotations to potential lockless readers.BUG: KCSAN: data-race in __ip6_datagram_connect / udpv6_sendmsgwrite to 0xffff888136d47a94 of 4 bytes by task 7681 on cpu 0: __ip6_datagram_connect+0x6e2/0x930 net/ipv6/datagram.c:221 ip6_datagram_connect+0x2a/0x40 net/ipv6/datagram.c:272 inet_dgram_connect+0x107/0x190 net/ipv4/af_inet.c:576 __sys_connect_file net/socket.c:1900 [inline] __sys_connect+0x197/0x1b0 net/socket.c:1917 __do_sys_connect net/socket.c:1927 [inline] __se_sys_connect net/socket.c:1924 [inline] __x64_sys_connect+0x3d/0x50 net/socket.c:1924 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaeread to 0xffff888136d47a94 of 4 bytes by task 7670 on cpu 1: udpv6_sendmsg+0xc60/0x16e0 net/ipv6/udp.c:1436 inet6_sendmsg+0x5f/0x80 net/ipv6/af_inet6.c:652 sock_sendmsg_nosec net/socket.c:705 [inline] sock_sendmsg net/socket.c:725 [inline] ____sys_sendmsg+0x39a/0x510 net/socket.c:2413 ___sys_sendmsg net/socket.c:2467 [inline] __sys_sendmmsg+0x267/0x4c0 net/socket.c:2553 __do_sys_sendmmsg net/socket.c:2582 [inline] __se_sys_sendmmsg net/socket.c:2579 [inline] __x64_sys_sendmmsg+0x53/0x60 net/socket.c:2579 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x50 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xaevalue changed: 0x00000000 -> 0xffffff9bReported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 7670 Comm: syz-executor.3 Tainted: G W 5.18.0-rc1-syzkaller-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011I chose to not add Fixes: tag because race has minor consequencesand stable teams busy enough.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49439 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fsl_rio: Fix refcount leak in fsl_rio_setupof_parse_phandle() returns a node pointer with refcountincremented, we should use of_node_put() on it when not need anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49446 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvdimm: Fix firmware activation deadlock scenariosLockdep reports the following deadlock scenarios for CXL root devicepower-management, device_prepare(), operations, and device_shutdown()operations for 'nd_region' devices: Chain exists of: &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(system_transition_mutex); lock(&nvdimm_bus->reconfig_mutex); lock(system_transition_mutex); lock(&nvdimm_region_key); Chain exists of: &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&cxl_root_key); lock(acpi_scan_lock); lock(&cxl_root_key); lock(&cxl_nvdimm_bridge_key);These stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()which walks the entire system device topology taking device_lock() alongthe way. The nvdimm_bus_lock() is protecting against unregistration,multiple simultaneous ops callers, and preventing activate_show() fromracing activate_store(). For the first 2, the lock is redundant.Unregistration already flushes all ops users, and sysfs already preventsmultiple threads to be active in an ops handler at the same time. Forthe last userspace should already be waiting for its lastactivate_store() to complete, and does not need activate_show() to flushthe write side, so this lock usage can be deleted in these attributes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix listen() setting the bar too high for the prealloc ringsAF_RXRPC's listen() handler lets you set the backlog up to 32 (if you bumpup the sysctl), but whilst the preallocation circular buffers have 32 slotsin them, one of them has to be a dead slot because we're using CIRC_CNT().This means that listen(rxrpc_sock, 32) will cause an oops when the socketis closed because rxrpc_service_prealloc_one() allocated one too many callsand rxrpc_discard_prealloc() won't then be able to get rid of them becauseit'll think the ring is empty. rxrpc_release_calls_on_socket() then triesto abort them, but oopses because call->peer isn't yet set.Fix this by setting the maximum backlog to RXRPC_BACKLOG_MAX - 1 to matchthe ring capacity. BUG: kernel NULL pointer dereference, address: 0000000000000086 ... RIP: 0010:rxrpc_send_abort_packet+0x73/0x240 [rxrpc] Call Trace: ? __wake_up_common_lock+0x7a/0x90 ? rxrpc_notify_socket+0x8e/0x140 [rxrpc] ? rxrpc_abort_call+0x4c/0x60 [rxrpc] rxrpc_release_calls_on_socket+0x107/0x1a0 [rxrpc] rxrpc_release+0xc9/0x1c0 [rxrpc] __sock_release+0x37/0xa0 sock_close+0x11/0x20 __fput+0x89/0x240 task_work_run+0x59/0x90 do_exit+0x319/0xaa0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49469 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix anon_dev leak in create_subvol()When btrfs_qgroup_inherit(), btrfs_alloc_tree_block, orbtrfs_insert_root() fail in create_subvol(), we return without freeinganon_dev. Reorganize the error handling in create_subvol() to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btmtksdio: fix use-after-free at btmtksdio_recv_eventWe should not access skb buffer data anymore after hci_recv_frame wascalled.[ 39.634809] BUG: KASAN: use-after-free in btmtksdio_recv_event+0x1b0[ 39.634855] Read of size 1 at addr ffffff80cf28a60d by task kworker[ 39.634962] Call trace:[ 39.634974] dump_backtrace+0x0/0x3b8[ 39.634999] show_stack+0x20/0x2c[ 39.635016] dump_stack_lvl+0x60/0x78[ 39.635040] print_address_description+0x70/0x2f0[ 39.635062] kasan_report+0x154/0x194[ 39.635079] __asan_report_load1_noabort+0x44/0x50[ 39.635099] btmtksdio_recv_event+0x1b0/0x1c4[ 39.635129] btmtksdio_txrx_work+0x6cc/0xac4[ 39.635157] process_one_work+0x560/0xc5c[ 39.635177] worker_thread+0x7ec/0xcc0[ 39.635195] kthread+0x2d0/0x3d0[ 39.635215] ret_from_fork+0x10/0x20[ 39.635247] Allocated by task 0:[ 39.635260] (stack is not available)[ 39.635281] Freed by task 2392:[ 39.635295] kasan_save_stack+0x38/0x68[ 39.635319] kasan_set_track+0x28/0x3c[ 39.635338] kasan_set_free_info+0x28/0x4c[ 39.635357] ____kasan_slab_free+0x104/0x150[ 39.635374] __kasan_slab_free+0x18/0x28[ 39.635391] slab_free_freelist_hook+0x114/0x248[ 39.635410] kfree+0xf8/0x2b4[ 39.635427] skb_free_head+0x58/0x98[ 39.635447] skb_release_data+0x2f4/0x410[ 39.635464] skb_release_all+0x50/0x60[ 39.635481] kfree_skb+0xc8/0x25c[ 39.635498] hci_event_packet+0x894/0xca4 [bluetooth][ 39.635721] hci_rx_work+0x1c8/0x68c [bluetooth][ 39.635925] process_one_work+0x560/0xc5c[ 39.635951] worker_thread+0x7ec/0xcc0[ 39.635970] kthread+0x2d0/0x3d0[ 39.635990] ret_from_fork+0x10/0x20[ 39.636021] The buggy address belongs to the object at ffffff80cf28a600 which belongs to the cache kmalloc-512 of size 512[ 39.636039] The buggy address is located 13 bytes inside of 512-byte region [ffffff80cf28a600, ffffff80cf28a800)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49471 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: cfo: check mac_id to avoid out-of-boundsSomehow, hardware reports incorrect mac_id and pollute memory. Check indexbefore we access the array. UBSAN: array-index-out-of-bounds in rtw89/phy.c:2517:23 index 188 is out of range for type 's32 [64]' CPU: 1 PID: 51550 Comm: irq/35-rtw89_pc Tainted: G OE Call Trace: show_stack+0x52/0x58 dump_stack_lvl+0x4c/0x63 dump_stack+0x10/0x12 ubsan_epilogue+0x9/0x45 __ubsan_handle_out_of_bounds.cold+0x44/0x49 ? __alloc_skb+0x92/0x1d0 rtw89_phy_cfo_parse+0x44/0x7f [rtw89_core] rtw89_core_rx+0x261/0x871 [rtw89_core] ? __alloc_skb+0xee/0x1d0 rtw89_pci_napi_poll+0x3fa/0x4ea [rtw89_pci] __napi_poll+0x33/0x1a0 net_rx_action+0x126/0x260 ? __queue_work+0x217/0x4c0 __do_softirq+0xd9/0x315 ? disable_irq_nosync+0x10/0x10 do_softirq.part.0+0x6d/0x90 __local_bh_enable_ip+0x62/0x70 rtw89_pci_interrupt_threadfn+0x182/0x1a6 [rtw89_pci] irq_thread_fn+0x28/0x60 irq_thread+0xc8/0x190 ? irq_thread_fn+0x60/0x60 kthread+0x16b/0x190 ? irq_thread_check_affinity+0xe0/0xe0 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: fix kernel crash at mt7921_pci_removeThe crash log shown it is possible that mt7921_irq_handler is called whiledevm_free_irq is being handled so mt76_free_device need to be postponeduntil devm_free_irq is completed to solve the crash we free the mt76 devicetoo early.[ 9299.339655] BUG: kernel NULL pointer dereference, address: 0000000000000008[ 9299.339705] #PF: supervisor read access in kernel mode[ 9299.339735] #PF: error_code(0x0000) - not-present page[ 9299.339768] PGD 0 P4D 0[ 9299.339786] Oops: 0000 [#1] SMP PTI[ 9299.339812] CPU: 1 PID: 1624 Comm: prepare-suspend Not tainted 5.15.14-1.fc32.qubes.x86_64 #1[ 9299.339863] Hardware name: Xen HVM domU, BIOS 4.14.3 01/20/2022[ 9299.339901] RIP: 0010:mt7921_irq_handler+0x1e/0x70 [mt7921e][ 9299.340048] RSP: 0018:ffffa81b80c27cb0 EFLAGS: 00010082[ 9299.340081] RAX: 0000000000000000 RBX: ffff98a4cb752020 RCX: ffffffffa96211c5[ 9299.340123] RDX: 0000000000000000 RSI: 00000000000d4204 RDI: ffff98a4cb752020[ 9299.340165] RBP: ffff98a4c28a62a4 R08: ffff98a4c37a96c0 R09: 0000000080150011[ 9299.340207] R10: 0000000040000000 R11: 0000000000000000 R12: ffff98a4c4eaa080[ 9299.340249] R13: ffff98a4c28a6360 R14: ffff98a4cb752020 R15: ffff98a4c28a6228[ 9299.340297] FS: 00007260840d3740(0000) GS:ffff98a4ef700000(0000) knlGS:0000000000000000[ 9299.340345] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9299.340383] CR2: 0000000000000008 CR3: 0000000004c56001 CR4: 0000000000770ee0[ 9299.340432] PKRU: 55555554[ 9299.340449] Call Trace:[ 9299.340467] [ 9299.340485] __free_irq+0x221/0x350[ 9299.340527] free_irq+0x30/0x70[ 9299.340553] devm_free_irq+0x55/0x80[ 9299.340579] mt7921_pci_remove+0x2f/0x40 [mt7921e][ 9299.340616] pci_device_remove+0x3b/0xa0[ 9299.340651] __device_release_driver+0x17a/0x240[ 9299.340686] device_driver_detach+0x3c/0xa0[ 9299.340714] unbind_store+0x113/0x130[ 9299.340740] kernfs_fop_write_iter+0x124/0x1b0[ 9299.340775] new_sync_write+0x15c/0x1f0[ 9299.340806] vfs_write+0x1d2/0x270[ 9299.340831] ksys_write+0x67/0xe0[ 9299.340857] do_syscall_64+0x3b/0x90[ 9299.340887] entry_SYSCALL_64_after_hwframe+0x44/0xae

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7915: fix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorFix possible NULL pointer dereference in mt7915_mac_fill_rx_vectorroutine if the chip does not support dbdc and the hw reports band_idxset to 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49496 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.koIf the driver support subdev mode, the parameter "dev->pm.dev" will beNULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmodmtk-vcodec-dec.ko.[ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80[ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c[ 4380.711509] sp : ffff80000819bc10[ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000[ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000[ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220[ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020[ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976[ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040[ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000[ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc[ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000[ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208[ 4380.786031] Call trace:[ 4380.788465] do_raw_spin_trylock+0x4/0x80[ 4380.792462] __pm_runtime_disable+0x2c/0x1b0[ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec][ 4380.802466] platform_remove+0x2c/0x60[ 4380.806204] __device_release_driver+0x194/0x250[ 4380.810810] driver_detach+0xc8/0x15c[ 4380.814462] bus_remove_driver+0x5c/0xb0[ 4380.818375] driver_unregister+0x34/0x64[ 4380.822288] platform_driver_unregister+0x18/0x24[ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec][ 4380.833240] __arm64_sys_delete_module+0x190/0x224[ 4380.838020] invoke_syscall+0x48/0x114[ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c[ 4380.846540] do_el0_svc+0x28/0x90[ 4380.849844] el0_svc+0x4c/0x100[ 4380.852975] el0t_64_sync_handler+0xec/0xf0[ 4380.857148] el0t_64_sync+0x190/0x194[ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49497 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: remove two BUG() from skb_checksum_help()I have a syzbot report that managed to get a crash in skb_checksum_help()If syzbot can trigger these BUG(), it makes sense to replacethem with more friendly WARN_ON_ONCE() since skb_checksum_help()can instead return an error code.Note that syzbot will still crash there, until real bug is fixed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49513 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: governor: Use kobject release() method to free dbs_dataThe struct dbs_data embeds a struct gov_attr_set andthe struct gov_attr_set embeds a kobject. Since every kobject must havea release() method and we can't use kfree() to free it directly,so introduce cpufreq_dbs_data_release() to release the dbs_data viathe kobject::release() method. This fixes the calltrace like below: ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debug_print_object+0xb8/0x100 lr : debug_print_object+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debug_print_object+0xb8/0x100 __debug_check_no_obj_freed+0x1d0/0x25c debug_check_no_obj_freed+0x24/0xa0 kfree+0x11c/0x440 cpufreq_dbs_governor_exit+0xa8/0xac cpufreq_exit_governor+0x44/0x90 cpufreq_set_policy+0x29c/0x570 store_scaling_governor+0x110/0x154 store+0xb0/0xe0 sysfs_kf_write+0x58/0x84 kernfs_fop_write_iter+0x12c/0x1c0 new_sync_write+0xf0/0x18c vfs_write+0x1cc/0x220 ksys_write+0x74/0x100 __arm64_sys_write+0x28/0x3c invoke_syscall.constprop.0+0x58/0xf0 do_el0_svc+0x70/0x170 el0_svc+0x54/0x190 el0t_64_sync_handler+0xa4/0x130 el0t_64_sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0 softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0 softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4[ rjw: Because can be freed by the gov_attr_set_put() in cpufreq_dbs_governor_exit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreq_dbs_data_release() function. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: always check VF VSI pointer valuesThe ice_get_vf_vsi function can return NULL in some cases, such as ifhandling messages during a reset where the VSI is being removed andrecreated.Several places throughout the driver do not bother to check whether thisVSI pointer is valid. Static analysis tools maybe report issues becausethey detect paths where a potentially NULL pointer could be dereferenced.Fix this by checking the return value of ice_get_vf_vsi everywhere.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49528 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: dw9714: Disable the regulator when the driver fails to probeWhen the driver fails to probe, we will get the following splat:[ 59.305988] ------------[ cut here ]------------[ 59.306417] WARNING: CPU: 2 PID: 395 at drivers/regulator/core.c:2257 _regulator_put+0x3ec/0x4e0[ 59.310345] RIP: 0010:_regulator_put+0x3ec/0x4e0[ 59.318362] Call Trace:[ 59.318582] [ 59.318765] regulator_put+0x1f/0x30[ 59.319058] devres_release_group+0x319/0x3d0[ 59.319420] i2c_device_probe+0x766/0x940Fix this by disabling the regulator in error handling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49530 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix double free in si_parse_power_table()In function si_parse_power_table(), array adev->pm.dpm.ps and its memberis allocated. If the allocation of each member fails, the array itselfis freed and returned with an error code. However, the array is laterfreed again in si_dpm_fini() function which is called when the functionreturns an error.This leads to potential double free of the array adev->pm.dpm.ps, aswell as leak of its array members, since the members are not freed inthe allocation function and the array is not nulled when freed.In addition adev->pm.dpm.num_ps, which keeps track of the allocatedarray member, is not updated until the member allocation issuccessfully finished, this could also lead to either use after free,or uninitialized variable access in si_dpm_fini().Fix this by postponing the free of the array until si_dpm_fini() andincrement adev->pm.dpm.num_ps everytime the array member is allocated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49533 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: Change max no of active probe SSID and BSSID to fw capabilityThe maximum number of SSIDs in a for active probe requests is currentlyreported as 16 (WLAN_SCAN_PARAMS_MAX_SSID) when registering the driver.The scan_req_params structure only has the capacity to hold 10 SSIDs.This leads to a buffer overflow which can be triggered fromwpa_supplicant in userspace. When copying the SSIDs into thescan_req_params structure in the ath11k_mac_op_hw_scan route, it canoverwrite the extraie pointer.Firmware supports 16 ssid * 4 bssid, for each ssid 4 bssid combo proberequest will be sent, so totally 64 probe requests supported. Soset both max ssid and bssid to 16 and 4 respectively. Remove theredundant macros of ssid and bssid.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01300-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: jack: Access input_dev under mutexIt is possible when using ASoC that input_dev is unregistered whilecalling snd_jack_report, which causes NULL pointer dereference.In order to prevent this serialize access to input_dev using mutex lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49543 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ath11k: fix the warning of dev_wake in mhi_pm_disable_transition()When test device recovery with below command, it has warning in messageas below.echo assert > /sys/kernel/debug/ath11k/wcn6855\ hw2.0/simulate_fw_crashecho assert > /sys/kernel/debug/ath11k/qca6390\ hw2.0/simulate_fw_crashwarning message:[ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash[ 1968.471364] ieee80211 phy0: Hardware restart was requested[ 1968.511305] ------------[ cut here ]------------[ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core[ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G W 5.17.0-rc3-wt-ath+ #579[ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021[ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi][ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi][ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89[ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286[ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922[ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24[ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27[ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac[ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24[ 1968.512310] FS: 0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000[ 1968.512405] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0[ 1968.512587] Call Trace:[ 1968.512672] [ 1968.512751] ? _raw_spin_unlock_irq+0x1f/0x40[ 1968.512859] mhi_pm_st_worker+0x3ac/0x790 [mhi][ 1968.512959] ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi][ 1968.513063] process_one_work+0x86a/0x1400[ 1968.513184] ? pwq_dec_nr_in_flight+0x230/0x230[ 1968.513312] ? move_linked_works+0x125/0x290[ 1968.513416] worker_thread+0x6db/0xf60[ 1968.513536] ? process_one_work+0x1400/0x1400[ 1968.513627] kthread+0x241/0x2d0[ 1968.513733] ? kthread_complete_and_exit+0x20/0x20[ 1968.513821] ret_from_fork+0x22/0x30[ 1968.513924] Reason is mhi_deassert_dev_wake() from mhi_device_put() is calledbut mhi_assert_dev_wake() from __mhi_device_get_sync() is not calledin progress of recovery. Commit 8e0559921f9a ("bus: mhi: core:Skip device wake in error or shutdown state") add check for thepm_state of mhi in __mhi_device_get_sync(), and the pm_state is notthe normal state untill recovery is completed, so it leads thedev_wake is not 0 and above warning print in mhi_pm_disable_transition()while checking mhi_cntrl->dev_wake.Add check in ath11k_pci_write32()/ath11k_pci_read32() to skip callmhi_device_put() if mhi_device_get_sync() does not really do wake,then the warning gone.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix potential array overflow in bpf_trampoline_get_progs()The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does notinclude BPF_TRAMP_MODIFY_RETURN bpf programs, so the number ofthe attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampolinecan exceed BPF_MAX_TRAMP_PROGS.When this happens, the assignment '*progs++ = aux->prog' inbpf_trampoline_get_progs() will cause progs array overflow as theprogs field in the bpf_tramp_progs struct can only hold at mostBPF_MAX_TRAMP_PROGS bpf programs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49552 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix combination of jit blinding and pointers to bpf subprogs.The combination of jit blinding and pointers to bpf subprogs causes:[ 36.989548] BUG: unable to handle page fault for address: 0000000100000001[ 36.990342] #PF: supervisor instruction fetch in kernel mode[ 36.990968] #PF: error_code(0x0010) - not-present page[ 36.994859] RIP: 0010:0x100000001[ 36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.[ 37.004091] Call Trace:[ 37.004351] [ 37.004576] ? bpf_loop+0x4d/0x70[ 37.004932] ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13bThe jit blinding logic didn't recognize that ld_imm64 with an addressof bpf subprogram is a special instruction and proceeded to randomize it.By itself it wouldn't have been an issue, but jit_subprogs() logicrelies on two step process to JIT all subprogs and then JIT themagain when addresses of all subprogs are known.Blinding process in the first JIT phase caused second JIT to missadjustment of special ld_imm64.Fix this issue by ignoring special ld_imm64 instructions that don't haveuser controlled constants and shouldn't be blinded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49554 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zsmalloc: fix races between asynchronous zspage free and page migrationThe asynchronous zspage free worker tries to lock a zspage's entire pagelist without defending against page migration. Since pages which haven'tyet been locked can concurrently migrate off the zspage page list whilelock_zspage() churns away, lock_zspage() can suffer from a few differentlethal races.It can lock a page which no longer belongs to the zspage and unsafelydereference page_private(), it can unsafely dereference a torn pointer tothe next page (since there's a data race), and it can observe a spuriousNULL pointer to the next page and thus not lock all of the zspage's pages(since a single page migration will reconstruct the entire page list, andcreate_page_chain() unconditionally zeroes out each list pointer in theprocess).Fix the races by using migrate_read_lock() in lock_zspage() to synchronizewith page migration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49558 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: double hook unregistration in netns path__nft_release_hooks() is called from pre_netns exit path whichunregisters the hooks, then the NETDEV_UNREGISTER event is triggeredwhich unregisters the hooks again.[ 565.221461] WARNING: CPU: 18 PID: 193 at net/netfilter/core.c:495 __nf_unregister_net_hook+0x247/0x270[...][ 565.246890] CPU: 18 PID: 193 Comm: kworker/u64:1 Tainted: G E 5.18.0-rc7+ #27[ 565.253682] Workqueue: netns cleanup_net[ 565.257059] RIP: 0010:__nf_unregister_net_hook+0x247/0x270[...][ 565.297120] Call Trace:[ 565.300900] [ 565.304683] nf_tables_flowtable_event+0x16a/0x220 [nf_tables][ 565.308518] raw_notifier_call_chain+0x63/0x80[ 565.312386] unregister_netdevice_many+0x54f/0xb50Unregister and destroy netdev hook from netns pre_exit via kfree_rcuso the NETDEV_UNREGISTER path see unregistered hooks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: check if cluster num is validSyzbot reported slab-out-of-bounds read in exfat_clear_bitmap.This was triggered by reproducer calling truncute with size 0,which causes the following trace:BUG: KASAN: slab-out-of-bounds in exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174Read of size 8 at addr ffff888115aa9508 by task syz-executor251/365Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack_lvl+0x1e2/0x24b lib/dump_stack.c:118 print_address_description+0x81/0x3c0 mm/kasan/report.c:233 __kasan_report mm/kasan/report.c:419 [inline] kasan_report+0x1a4/0x1f0 mm/kasan/report.c:436 __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:309 exfat_clear_bitmap+0x147/0x490 fs/exfat/balloc.c:174 exfat_free_cluster+0x25a/0x4a0 fs/exfat/fatent.c:181 __exfat_truncate+0x99e/0xe00 fs/exfat/file.c:217 exfat_truncate+0x11b/0x4f0 fs/exfat/file.c:243 exfat_setattr+0xa03/0xd40 fs/exfat/file.c:339 notify_change+0xb76/0xe10 fs/attr.c:336 do_truncate+0x1ea/0x2d0 fs/open.c:65Move the is_valid_cluster() helper from fatent.c to a commonheader to make it reusable in other *.c files. And add is_valid_cluster()to validate if cluster number is within valid range in exfat_clear_bitmap()and exfat_set_bitmap().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: conntrack: re-fetch conntrack after insertionIn case the conntrack is clashing, insertion can free skb->_nfct andset skb->_nfct to the already-confirmed entry.This wasn't found before because the conntrack entry and the extensionspace used to free'd after an rcu grace period, plus the race needsevents enabled to trigger.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix data-races around sysctl_fib_multipath_hash_fields.While reading sysctl_fib_multipath_hash_fields, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix data-races around sysctl_tcp_migrate_req.While reading sysctl_tcp_migrate_req, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_qrv.While reading sysctl_igmp_qrv, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. qrv ?: READ_ONCE(net->ipv4.sysctl_igmp_qrv);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: Fix a data-race around sysctl_tcp_mtu_probe_floor.While reading sysctl_tcp_mtu_probe_floor, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix a data-race around sysctl_ip_autobind_reuse.While reading sysctl_ip_autobind_reuse, it can be changed concurrently.Thus, we need to add READ_ONCE() to its reader.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49608 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ralink: Check for null return of devm_kcallocBecause of the possible failure of the allocation, data->domains mightbe NULL pointer and will cause the dereference of the NULL pointerlater.Therefore, it might be better to check it and directly return -ENOMEMwithout releasing data manually if fails, because the comment of thedevm_kmalloc() says "Memory allocated with this function isautomatically freed on driver detach.".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: avoid skb access on nf_stolenWhen verdict is NF_STOLEN, the skb might have been freed.When tracing is enabled, this can result in a use-after-free:1. access to skb->nf_trace2. access to skb->mark3. computation of trace id4. dump of packet payloadTo avoid 1, keep a cached copy of skb->nf_trace in thetrace state struct.Refresh this copy whenever verdict is != STOLEN.Avoid 2 by skipping skb->mark access if verdict is STOLEN.3 is avoided by precomputing the trace id.Only dump the packet when verdict is not "STOLEN".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Fix data-races around nexthop_compat_mode.While reading nexthop_compat_mode, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: Fix data-races around sysctl_icmp_echo_enable_probe.While reading sysctl_icmp_echo_enable_probe, it can be changedconcurrently. Thus, we need to add READ_ONCE() to its readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/selftests: fix subtraction overflow bugOn some machines hole_end can be small enough to cause subtractionoverflow. On the other side (addr + 2 * min_alignment) can overflowin case of mock tests. This patch should handle both cases.(cherry picked from commit ab3edc679c552a466e4bf0b11af3666008bd65a2)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix a data-race around sysctl_fib_sync_mem.While reading sysctl_fib_sync_mem, it can be changed concurrently.So, we need to add READ_ONCE() to avoid a data-race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49654 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: qca8k: reset cpu port on MTU changeIt was discovered that the Documentation lacks of a fundamental detailon how to correctly change the MAX_FRAME_SIZE of the switch.In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, theswitch panics and cease to send any packet. This cause the mgmt ethernetsystem to not receive any packet (the slow fallback still works) andmakes the device not reachable. To recover from this a switch reset isrequired.To correctly handle this, turn off the cpu ports before changing theMAX_FRAME_SIZE and turn on again after the value is applied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix insufficient bounds propagation from adjust_scalar_min_max_valsKuee reported a corner case where the tnum becomes constant after the callto __reg_bound_offset(), but the register's bounds are not, that is, itsmin bounds are still not equal to the register's max bounds.This in turn allows to leak pointers through turning a pointer register asis into an unknown scalar via adjust_ptr_min_max_vals().Before: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 9: (07) r3 += -32767 ; R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)) <--- [*] 10: (95) exitWhat can be seen here is that R3=scalar(umin=32767,umax=32768,var_off=(0x7fff;0x8000)) after the operation R3 += -32767 results in a 'malformed' constant, thatis, R3_w=scalar(imm=0,umax=1,var_off=(0x0; 0x0)). Intersecting with var_off hasnot been done at that point via __update_reg_bounds(), which would have improvedthe umax to be equal to umin.Refactor the tnum <> min/max bounds information flow into a reg_bounds_sync()helper and use it consistently everywhere. After the fix, bounds have beencorrected to R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) and thus the registeris regarded as a 'proper' constant scalar of 0.After: func#0 @0 0: R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 0: (b7) r0 = 1 ; R0_w=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) 1: (b7) r3 = 0 ; R3_w=scalar(imm=0,umax=0,var_off=(0x0; 0x0)) 2: (87) r3 = -r3 ; R3_w=scalar() 3: (87) r3 = -r3 ; R3_w=scalar() 4: (47) r3 |= 32767 ; R3_w=scalar(smin=-9223372036854743041,umin=32767,var_off=(0x7fff; 0xffffffffffff8000),s32_min=-2147450881) 5: (75) if r3 s>= 0x0 goto pc+1 ; R3_w=scalar(umin=9223372036854808575,var_off=(0x8000000000007fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 6: (95) exit from 5 to 7: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881) R10=fp(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) 7: (d5) if r3 s<= 0x8000 goto pc+1 ; R3=scalar(umin=32769,umax=9223372036854775807,var_off=(0x7fff; 0x7fffffffffff8000),s32_min=-2147450881,u32_min=32767) 8: (95) exit from 7 to 9: R0=scalar(imm=1,umin=1,umax=1,var_off=(0x1; 0x0)) R1=ctx(off=0,imm=0,umax=0,var_off=(0x0; 0x0)) R3=scalar(umin=32767,umax=32768,var_off=(0x7fff; 0x8000)) R10=fp(off=0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: m_can: m_can_{read_fifo,echo_tx_event}(): shift timestamp to full 32 bitsIn commit 1be37d3b0414 ("can: m_can: fix periph RX path: userx-offload to ensure skbs are sent from softirq context") the RX pathfor peripheral devices was switched to RX-offload.Received CAN frames are pushed to RX-offload together with atimestamp. RX-offload is designed to handle overflows of the timestampcorrectly, if 32 bit timestamps are provided.The timestamps of m_can core are only 16 bits wide. So this patchshifts them to full 32 bit before passing them to RX-offload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix lockdep splat in in6_dump_addrs()As reported by syzbot, we should not use rcu_dereference()when rcu_read_lock() is not held.WARNING: suspicious RCU usage5.19.0-rc2-syzkaller #0 Not taintednet/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz-executor326/3617: #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223stack backtrace:CPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175 inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300 netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275 __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380 netlink_dump_start include/linux/netlink.h:245 [inline] rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734 ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492 ___sys_sendmsg+0xf3/0x170 net/socket.c:2546 __sys_sendmsg net/socket.c:2575 [inline] __do_sys_sendmsg net/socket.c:2584 [inline] __se_sys_sendmsg net/socket.c:2582 [inline] __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: move bc link creation back to tipc_node_createShuang Li reported a NULL pointer dereference crash: [] BUG: kernel NULL pointer dereference, address: 0000000000000068 [] RIP: 0010:tipc_link_is_up+0x5/0x10 [tipc] [] Call Trace: [] [] tipc_bcast_rcv+0xa2/0x190 [tipc] [] tipc_node_bc_rcv+0x8b/0x200 [tipc] [] tipc_rcv+0x3af/0x5b0 [tipc] [] tipc_udp_recv+0xc7/0x1e0 [tipc]It was caused by the 'l' passed into tipc_bcast_rcv() is NULL. When itcreates a node in tipc_node_check_dest(), after inserting the new nodeinto hashtable in tipc_node_create(), it creates the bc link. However,there is a gap between this insert and bc link creation, a bc packetmay come in and get the node from the hashtable then try to dereferenceits bc link, which is NULL.This patch is to fix it by moving the bc link creation before insertinginto the hashtable.Note that for a preliminary node becoming "real", the bc link creationshould also be called before it's rehashed, as we don't create it forpreliminary nodes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not assume transport header is always setRewrite tests in ip6erspan_tunnel_xmit() anderspan_fb_xmit() to not assume transport header is set.syzbot reported:WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline]WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Modules linked in:CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6e53f #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00RSP: 0018:ffffc90005daf910 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0Call Trace:__netdev_start_xmit include/linux/netdevice.h:4805 [inline]netdev_start_xmit include/linux/netdevice.h:4819 [inline]xmit_one net/core/dev.c:3588 [inline]dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342__dev_xmit_skb net/core/dev.c:3815 [inline]__dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219dev_queue_xmit include/linux/netdevice.h:2994 [inline]tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229kthread+0x2e9/0x3a0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix use-after-free Read in tipc_named_reinitsyzbot found the following issue on:==================================================================BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0net/tipc/name_distr.c:413Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted5.18.0-rc4-syzkaller-00878-g17d49e6e8012 #0Hardware name: Google Compute Engine/Google Compute Engine,BIOS Google 01/01/2011Workqueue: events tipc_net_finalize_workCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 [...]==================================================================In the commitd966ddcc3821 ("tipc: fix a deadlock when flushing scheduled work"),the cancel_work_sync() function just to make sure ONLY the worktipc_net_finalize_work() is executing/pending on any CPU completed beforetipc namespace is destroyed through tipc_exit_net(). But this functionis not guaranteed the work is the last queued. So, the destroyed instancemay be accessed in the work which will try to enqueue later.In order to completely fix, we re-order the calling of cancel_work_sync()to make sure the work tipc_net_finalize_work() was last queued and itmust be completed by calling cancel_work_sync().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49697 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix request_sock leak in sk lookup helpersA customer reported a request_socket leak in a Calico cloud environment. Wefound that a BPF program was doing a socket lookup with takes a refcnt onthe socket and that it was finding the request_socket but returning the parentLISTEN socket via sk_to_full_sk() without decrementing the child request socket1st, resulting in request_sock slab object leak. This patch retains theexisting behaviour of returning full socks to the caller but it also decrementsthe child request_socket if one is present before doing so to prevent the leak.Thanks to Curtis Taylor for all the help in diagnosing and testing this. Andthanks to Antoine Tenart for the reproducer and patch input.v2 of this patch contains, refactor as per Daniel Borkmann's suggestions tovalidate RCU flags on the listen socket so that it balances with bpf_sk_release()and update comments as per Martin KaFai Lau's suggestion. One small change toDaniels suggestion, put "sk = sk2" under "if (sk2 != sk)" to avoid an extrainstruction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix hang during unmount when block group reclaim task is runningWhen we start an unmount, at close_ctree(), if we have the reclaim taskrunning and in the middle of a data block group relocation, we can triggera deadlock when stopping an async reclaim task, producing a trace like thefollowing:[629724.498185] task:kworker/u16:7 state:D stack: 0 pid:681170 ppid: 2 flags:0x00004000[629724.499760] Workqueue: events_unbound btrfs_async_reclaim_metadata_space [btrfs][629724.501267] Call Trace:[629724.501759] [629724.502174] __schedule+0x3cb/0xed0[629724.502842] schedule+0x4e/0xb0[629724.503447] btrfs_wait_on_delayed_iputs+0x7c/0xc0 [btrfs][629724.504534] ? prepare_to_wait_exclusive+0xc0/0xc0[629724.505442] flush_space+0x423/0x630 [btrfs][629724.506296] ? rcu_read_unlock_trace_special+0x20/0x50[629724.507259] ? lock_release+0x220/0x4a0[629724.507932] ? btrfs_get_alloc_profile+0xb3/0x290 [btrfs][629724.508940] ? do_raw_spin_unlock+0x4b/0xa0[629724.509688] btrfs_async_reclaim_metadata_space+0x139/0x320 [btrfs][629724.510922] process_one_work+0x252/0x5a0[629724.511694] ? process_one_work+0x5a0/0x5a0[629724.512508] worker_thread+0x52/0x3b0[629724.513220] ? process_one_work+0x5a0/0x5a0[629724.514021] kthread+0xf2/0x120[629724.514627] ? kthread_complete_and_exit+0x20/0x20[629724.515526] ret_from_fork+0x22/0x30[629724.516236] [629724.516694] task:umount state:D stack: 0 pid:719055 ppid:695412 flags:0x00004000[629724.518269] Call Trace:[629724.518746] [629724.519160] __schedule+0x3cb/0xed0[629724.519835] schedule+0x4e/0xb0[629724.520467] schedule_timeout+0xed/0x130[629724.521221] ? lock_release+0x220/0x4a0[629724.521946] ? lock_acquired+0x19c/0x420[629724.522662] ? trace_hardirqs_on+0x1b/0xe0[629724.523411] __wait_for_common+0xaf/0x1f0[629724.524189] ? usleep_range_state+0xb0/0xb0[629724.524997] __flush_work+0x26d/0x530[629724.525698] ? flush_workqueue_prep_pwqs+0x140/0x140[629724.526580] ? lock_acquire+0x1a0/0x310[629724.527324] __cancel_work_timer+0x137/0x1c0[629724.528190] close_ctree+0xfd/0x531 [btrfs][629724.529000] ? evict_inodes+0x166/0x1c0[629724.529510] generic_shutdown_super+0x74/0x120[629724.530103] kill_anon_super+0x14/0x30[629724.530611] btrfs_kill_super+0x12/0x20 [btrfs][629724.531246] deactivate_locked_super+0x31/0xa0[629724.531817] cleanup_mnt+0x147/0x1c0[629724.532319] task_work_run+0x5c/0xa0[629724.532984] exit_to_user_mode_prepare+0x1a6/0x1b0[629724.533598] syscall_exit_to_user_mode+0x16/0x40[629724.534200] do_syscall_64+0x48/0x90[629724.534667] entry_SYSCALL_64_after_hwframe+0x44/0xae[629724.535318] RIP: 0033:0x7fa2b90437a7[629724.535804] RSP: 002b:00007ffe0b7e4458 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6[629724.536912] RAX: 0000000000000000 RBX: 00007fa2b9182264 RCX: 00007fa2b90437a7[629724.538156] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000555d6cf20dd0[629724.539053] RBP: 0000555d6cf20ba0 R08: 0000000000000000 R09: 00007ffe0b7e3200[629724.539956] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[629724.540883] R13: 0000555d6cf20dd0 R14: 0000555d6cf20cb0 R15: 0000000000000000[629724.541796] This happens because:1) Before entering close_ctree() we have the async block group reclaim task running and relocating a data block group;2) There's an async metadata (or data) space reclaim task running;3) We enter close_ctree() and park the cleaner kthread;4) The async space reclaim task is at flush_space() and runs all the existing delayed iputs;5) Before the async space reclaim task calls btrfs_wait_on_delayed_iputs(), the block group reclaim task which is doing the data block group relocation, creates a delayed iput at replace_file_extents() (called when COWing leaves that have file extent items pointing to relocated data exten---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49706 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:zonefs: fix zonefs_iomap_begin() for readsIf a readahead is issued to a sequential zone file with an offsetexactly equal to the current file size, the iomap type is set toIOMAP_UNWRITTEN, which will prevent an IO, but the iomap length iscalculated as 0. This causes a WARN_ON() in iomap_iter():[17309.548939] WARNING: CPU: 3 PID: 2137 at fs/iomap/iter.c:34 iomap_iter+0x9cf/0xe80[...][17309.650907] RIP: 0010:iomap_iter+0x9cf/0xe80[...][17309.754560] Call Trace:[17309.757078] [17309.759240] ? lock_is_held_type+0xd8/0x130[17309.763531] iomap_readahead+0x1a8/0x870[17309.767550] ? iomap_read_folio+0x4c0/0x4c0[17309.771817] ? lockdep_hardirqs_on_prepare+0x400/0x400[17309.778848] ? lock_release+0x370/0x750[17309.784462] ? folio_add_lru+0x217/0x3f0[17309.790220] ? reacquire_held_locks+0x4e0/0x4e0[17309.796543] read_pages+0x17d/0xb60[17309.801854] ? folio_add_lru+0x238/0x3f0[17309.807573] ? readahead_expand+0x5f0/0x5f0[17309.813554] ? policy_node+0xb5/0x140[17309.819018] page_cache_ra_unbounded+0x27d/0x450[17309.825439] filemap_get_pages+0x500/0x1450[17309.831444] ? filemap_add_folio+0x140/0x140[17309.837519] ? lock_is_held_type+0xd8/0x130[17309.843509] filemap_read+0x28c/0x9f0[17309.848953] ? zonefs_file_read_iter+0x1ea/0x4d0 [zonefs][17309.856162] ? trace_contention_end+0xd6/0x130[17309.862416] ? __mutex_lock+0x221/0x1480[17309.868151] ? zonefs_file_read_iter+0x166/0x4d0 [zonefs][17309.875364] ? filemap_get_pages+0x1450/0x1450[17309.881647] ? __mutex_unlock_slowpath+0x15e/0x620[17309.888248] ? wait_for_completion_io_timeout+0x20/0x20[17309.895231] ? lock_is_held_type+0xd8/0x130[17309.901115] ? lock_is_held_type+0xd8/0x130[17309.906934] zonefs_file_read_iter+0x356/0x4d0 [zonefs][17309.913750] new_sync_read+0x2d8/0x520[17309.919035] ? __x64_sys_lseek+0x1d0/0x1d0Furthermore, this causes iomap_readahead() to loop forever asiomap_readahead_iter() always returns 0, making no progress.Fix this by treating reads after the file size as access to holes,setting the iomap type to IOMAP_HOLE, the iomap addr to IOMAP_NULL_ADDRand using the length argument as is for the iomap length. To simplifythe code with this change, zonefs_iomap_begin() is split into the readvariant, zonefs_read_iomap_begin() and zonefs_read_iomap_ops, and thewrite variant, zonefs_write_iomap_begin() and zonefs_write_iomap_ops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cfi: Fix __cfi_slowpath_diag RCU usage with cpuidleRCU_NONIDLE usage during __cfi_slowpath_diag can result in an invalidRCU state in the cpuidle code path: WARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:613 rcu_eqs_enter+0xe4/0x138 ... Call trace: rcu_eqs_enter+0xe4/0x138 rcu_idle_enter+0xa8/0x100 cpuidle_enter_state+0x154/0x3a8 cpuidle_enter+0x3c/0x58 do_idle.llvm.6590768638138871020+0x1f4/0x2ec cpu_startup_entry+0x28/0x2c secondary_start_kernel+0x1b8/0x220 __secondary_switched+0x94/0x98Instead, call rcu_irq_enter/exit to wake up RCU only when needed anddisable interrupts for the entire CFI shadow/module check when we do.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sock: redo the psock vs ULP protection checkCommit 8a59f9d1e3d4 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()")has moved the inet_csk_has_ulp(sk) check from sk_psock_init() tothe new tcp_bpf_update_proto() function. I'm guessing that thiswas done to allow creating psocks for non-inet sockets.Unfortunately the destruction path for psock includes the ULPunwind, so we need to fail the sk_psock_init() itself.Otherwise if ULP is already present we'll notice that later,and call tcp_update_ulp() with the sk_proto of the ULPitself, which will most likely result in the ULP loopingits callbacks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49743 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ovl: Use "buf" flexible array for memcpy() destinationThe "buf" flexible array needs to be the memcpy() destination to avoidfalse positive run-time warning from the recent FORTIFY_SOURCEhardening: memcpy: detected field-spanning write (size 93) of single field "&fh->fb" at fs/overlayfs/export.c:799 (size 21)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: designware: use casting of u64 in clock multiplication to avoid overflowIn functions i2c_dw_scl_lcnt() and i2c_dw_scl_hcnt() may have overflowby depending on the values of the given parameters including the ic_clk.For example in our use case where ic_clk is larger than one million,multiplication of ic_clk * 4700 will result in 32 bit overflow.Add cast of u64 to the calculation to avoid multiplication overflow, anduse the corresponding define for divide.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/highbank: Fix memory leak in highbank_mc_probe()When devres_open_group() fails, it returns -ENOMEM without freeing memoryallocated by edac_mc_alloc().Call edac_mc_free() on the error handling path to avoid a memory leak. [ bp: Massage commit message. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:reset: uniphier-glue: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(res) invoked,if platform_get_resource() returns NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: always report error in run_one_delayed_ref()Currently we have a btrfs_debug() for run_one_delayed_ref() failure, butif end users hit such problem, there will be no chance thatbtrfs_debug() is enabled. This can lead to very little useful info fordebugging.This patch will:- Add extra info for error reporting Including: * logical bytenr * num_bytes * type * action * ref_mod- Replace the btrfs_debug() with btrfs_err()- Move the error reporting into run_one_delayed_ref() This is to avoid use-after-free, the @node can be freed in the caller.This error should only be triggered at most once.As if run_one_delayed_ref() failed, we trigger the error message, thencausing the call chain to error out:btrfs_run_delayed_refs()`- btrfs_run_delayed_refs() `- btrfs_run_delayed_refs_for_head() `- run_one_delayed_ref()And we will abort the current transaction in btrfs_run_delayed_refs().If we have to run delayed refs for the abort transaction,run_one_delayed_ref() will just cleanup the refs and do nothing, thus nonew error messages would be output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ntfs: check overflow when iterating ATTR_RECORDsKernel iterates over ATTR_RECORDs in mft record in ntfs_attr_find(). Because the ATTR_RECORDs are next to each other, kernel can get the nextATTR_RECORD from end address of current ATTR_RECORD, through currentATTR_RECORD length field.The problem is that during iteration, when kernel calculates the endaddress of current ATTR_RECORD, kernel may trigger an integer overflow bugin executing `a = (ATTR_RECORD*)((u8*)a + le32_to_cpu(a->length))`. Thismay wrap, leading to a forever iteration on 32bit systems.This patch solves it by adding some checks on calculating end addressof current ATTR_RECORD during iteration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent bpf program recursion for raw tracepoint probesWe got report from sysbot [1] about warnings that were caused bybpf program attached to contention_begin raw tracepoint triggeringthe same tracepoint by using bpf_trace_printk helper that takestrace_printk_lock lock. Call Trace: ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90 bpf_trace_printk+0x2b/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 bpf_trace_printk+0x3f/0xe0 bpf_prog_a9aec6167c091eef_prog+0x1f/0x24 bpf_trace_run2+0x26/0x90 native_queued_spin_lock_slowpath+0x1c6/0x2b0 _raw_spin_lock_irqsave+0x44/0x50 __unfreeze_partials+0x5b/0x160 ...The can be reproduced by attaching bpf program as raw tracepoint oncontention_begin tracepoint. The bpf prog calls bpf_trace_printkhelper. Then by running perf bench the spin lock code is forced totake slow path and call contention_begin tracepoint.Fixing this by skipping execution of the bpf program if it'salready running, Using bpf prog 'active' field, which is beingcurrently used by trampoline programs for the same reason.Moving bpf_prog_inc_misses_counter to syscall.c becausetrampoline.c is compiled in just for CONFIG_BPF_JIT option.[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: use a dedicated spinlock for trans_fdShamelessly copying the explanation from Tetsuo Handa's suggestedpatch[1] (slightly reworded):syzbot is reporting inconsistent lock state in p9_req_put()[2],for p9_tag_remove() from p9_req_put() from IRQ context is usingspin_lock_irqsave() on "struct p9_client"->lock but trans_fd(not from IRQ context) is using spin_lock().Since the locks actually protect different things in client.c and intrans_fd.c, just replace trans_fd.c's lock by a new one specific to thetransport (client.c's protect the idr for fid/tag allocations,while trans_fd.c's protects its own req list and request status fieldthat acts as the transport's state machine)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p: trans_fd/p9_conn_cancel: drop client lock earliersyzbot reported a double-lock here and we no longer need thislock after requests have been moved off to local list:just drop the lock earlier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49785 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Add overflow check in sgx_validate_offset_length()sgx_validate_offset_length() function verifies "offset" and "length"arguments provided by userspace, but was missing an overflow check ontheir addition. Add it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49803 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: Fix memory leak of nsim_dev->fa_cookiekmemleak reports this issue:unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] __kmalloc+0x49/0x150 [<000000005292b8c6>] nsim_dev_trap_fa_cookie_write+0xc1/0x210 [netdevsim] [<0000000093d78e77>] full_proxy_write+0xf3/0x180 [<000000005a662c16>] vfs_write+0x1c5/0xaf0 [<000000007aabf84a>] ksys_write+0xed/0x1c0 [<000000005f1d2e47>] do_syscall_64+0x3b/0x90 [<000000006001c6ec>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe issue occurs in the following scenarios:nsim_dev_trap_fa_cookie_write() kmalloc() fa_cookie nsim_dev->fa_cookie = fa_cookie..nsim_drv_remove()The fa_cookie allocked in nsim_dev_trap_fa_cookie_write() is not freed. Tofix, add kfree(nsim_dev->fa_cookie) to nsim_drv_remove().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: microchip: sparx5: Fix potential null-ptr-deref in sparx_stats_init() and sparx5_start()sparx_stats_init() calls create_singlethread_workqueue() and notchecked the ret value, which may return NULL. And a null-ptr-deref mayhappen:sparx_stats_init() create_singlethread_workqueue() # failed, sparx5->stats_queue is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL. So assparx5_start().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: don't leak tagger-owned storage on switch driver unbindIn the initial commit dc452a471dba ("net: dsa: introduce tagger-ownedstorage for private and shared data"), we had a call totag_ops->disconnect(dst) issued from dsa_tree_free(), which is called attree teardown time.There were problems with connecting to a switch tree as a whole, so thisgot reworked to connecting to individual switches within the tree. Inthis process, tag_ops->disconnect(ds) was made to be called only fromswitch.c (cross-chip notifiers emitted as a result of dynamic tag protochanges), but the normal driver teardown code path wasn't replaced withanything.Solve this problem by adding a function that does the opposite ofdsa_switch_setup_tag_protocol(), which is called from the equivalentspot in dsa_switch_teardown(). The positioning here also ensures that wewon't have any use-after-free in tagging protocol (*rcv) ops, since theteardown sequence is as follows:dsa_tree_teardown-> dsa_tree_teardown_master -> dsa_master_teardown -> unsets master->dsa_ptr, making no further packets match the ETH_P_XDSA packet type handler-> dsa_tree_teardown_ports -> dsa_port_teardown -> dsa_slave_destroy -> unregisters DSA net devices, there is even a synchronize_net() in unregister_netdevice_many()-> dsa_tree_teardown_switches -> dsa_switch_teardown -> dsa_switch_teardown_tag_protocol -> finally frees the tagger-owned storage

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hugetlbfs: don't delete error page from pagecacheThis change is very similar to the change that was made for shmem [1], andit solves the same problem but for HugeTLBFS instead.Currently, when poison is found in a HugeTLB page, the page is removedfrom the page cache. That means that attempting to map or read thathugepage in the future will result in a new hugepage being allocatedinstead of notifying the user that the page was poisoned. As [1] states,this is effectively memory corruption.The fix is to leave the page in the page cache. If the user attempts touse a poisoned HugeTLB page with a syscall, the syscall will fail withEIO, the same error code that shmem uses. For attempts to map the page,the thread will get a BUS_MCEERR_AR SIGBUS.[1]: commit a76054266661 ("mm: shmem: don't truncate page if memory failure happens")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: initialize device's zone info for seedingWhen performing seeding on a zoned filesystem it is necessary toinitialize each zoned device's btrfs_zoned_device_info structure,otherwise mounting the filesystem will cause a NULL pointer dereference.This was uncovered by fstests' testcase btrfs/163.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: clone zoned device info when cloning a deviceWhen cloning a btrfs_device, we're not cloning the associatedbtrfs_zoned_device_info structure of the device in case of a zonedfilesystem.Later on this leads to a NULL pointer dereference when accessing thedevice's zone_info for instance when setting a zone as active.This was uncovered by fstests' testcase btrfs/161.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, test_run: Fix alignment problem in bpf_prog_test_run_skb()We got a syzkaller problem because of aarch64 alignment faultif KFENCE enabled. When the size from user bpf program is an oddnumber, like 399, 407, etc, it will cause the struct skb_shared_info'sunaligned access. As seen below: BUG: KFENCE: use-after-free read in __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 Use-after-free read at 0xffff6254fffac077 (in kfence-#213): __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:26 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] arch_atomic_inc include/linux/atomic-arch-fallback.h:270 [inline] atomic_inc include/asm-generic/atomic-instrumented.h:241 [inline] __skb_clone+0x23c/0x2a0 net/core/skbuff.c:1032 skb_clone+0xf4/0x214 net/core/skbuff.c:1481 ____bpf_clone_redirect net/core/filter.c:2433 [inline] bpf_clone_redirect+0x78/0x1c0 net/core/filter.c:2420 bpf_prog_d3839dd9068ceb51+0x80/0x330 bpf_dispatcher_nop_func include/linux/bpf.h:728 [inline] bpf_test_run+0x3c0/0x6c0 net/bpf/test_run.c:53 bpf_prog_test_run_skb+0x638/0xa7c net/bpf/test_run.c:594 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 kfence-#213: 0xffff6254fffac000-0xffff6254fffac196, size=407, cache=kmalloc-512 allocated by task 15074 on cpu 0 at 1342.585390s: kmalloc include/linux/slab.h:568 [inline] kzalloc include/linux/slab.h:675 [inline] bpf_test_init.isra.0+0xac/0x290 net/bpf/test_run.c:191 bpf_prog_test_run_skb+0x11c/0xa7c net/bpf/test_run.c:512 bpf_prog_test_run kernel/bpf/syscall.c:3148 [inline] __do_sys_bpf kernel/bpf/syscall.c:4441 [inline] __se_sys_bpf+0xad0/0x1634 kernel/bpf/syscall.c:4381 __arm64_sys_bpf+0x50/0x60 kernel/bpf/syscall.c:4381To fix the problem, we adjust @size so that (@size + @hearoom) is amultiple of SMP_CACHE_BYTES. So we make sure the struct skb_shared_infois aligned to a cache line.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_pcie_read_bios_cfgipc_pcie_read_bios_cfg() is using the acpi_evaluate_dsm() toobtain the wwan power state configuration from BIOS but isnot freeing the acpi_object. The acpi_evaluate_dsm() returnedacpi_object to be freed.Free the acpi_object after use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: fix memory leak in prestera_rxtx_switch_init()When prestera_sdma_switch_init() failed, the memory pointed to bysw->rxtx isn't released. Fix it. Only be compiled, not be tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapbether: fix issue of invalid opcode in lapbeth_open()If lapb_register() failed when lapb device goes to up for the first time,the NAPI is not disabled. As a result, the invalid opcode issue isreported when the lapb device goes to up for the second time.The stack info is as follows:[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442![ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0[ 1958.332310][T11356] Call Trace:[ 1958.332817][T11356] [ 1958.336135][T11356] lapbeth_open+0x18/0x90[ 1958.337446][T11356] __dev_open+0x258/0x490[ 1958.341672][T11356] __dev_change_flags+0x4d4/0x6a0[ 1958.345325][T11356] dev_change_flags+0x93/0x160[ 1958.346027][T11356] devinet_ioctl+0x1276/0x1bf0[ 1958.346738][T11356] inet_ioctl+0x1c8/0x2d0[ 1958.349638][T11356] sock_ioctl+0x5d1/0x750[ 1958.356059][T11356] __x64_sys_ioctl+0x3ec/0x1790[ 1958.365594][T11356] do_syscall_64+0x35/0x80[ 1958.366239][T11356] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 1958.377381][T11356]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_headerThis is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-valuein tipc_nl_compat_name_table_dump") where it should have type castedsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negativevalue.syzbot reported a call trace because of it: BUG: KMSAN: uninit-value in ... tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934 __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238 tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321 tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324 genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline] genl_family_rcv_msg net/netlink/genetlink.c:775 [inline] genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792 netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501 genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix memory leak in ipc_wwan_dellinkIOSM driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch sets needs_free_netdev to true when registersnetwork device, which makes netdev subsystem call free_netdev()automatically after unregister_netdevice().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix panic on frag_list with mixed head alloc typesSince commit 3dcbdb134f32 ("net: gso: Fix skb_segment splat whensplitting gso_size mangled skb having linear-headed frag_list"), it isallowed to change gso_size of a GRO packet. However, that commit assumesthat "checking the first list_skb member suffices; i.e if either of thelist_skb members have non head_frag head, then the first one has too".It turns out this assumption does not hold. We've seen BUG_ON being hitin skb_segment when skbs on the frag_list had differing head_frag withthe vmxnet3 driver. This happens because __netdev_alloc_skb and__napi_alloc_skb can return a skb that is page backed or kmalloceddepending on the requested size. As the result, the last small skb inthe GRO packet can be kmalloced.There are three different locations where this can be fixed:(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_list.(3) Walk the frag_list in skb_segment when determining whether NETIF_F_SG should be cleared. This of course slows things down.This patch implements (3). To limit the performance impact inskb_segment, the list is walked only for skbs with SKB_GSO_DODGY setthat have gso_size changed. Normal paths thus will not hit it.We could check only the last skb but since we need to walk the wholelist anyway, let's stay on the safe side.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix wrong reg type conversion in release_reference()Some helper functions will allocate memory. To avoid memory leaks, theverifier requires the eBPF program to release these memories by callingthe corresponding helper functions.When a resource is released, all pointer registers corresponding to theresource should be invalidated. The verifier use release_references() todo this job, by apply __mark_reg_unknown() to each relevant register.It will give these registers the type of SCALAR_VALUE. A register thatwill contain a pointer value at runtime, but of type SCALAR_VALUE, whichmay allow the unprivileged user to get a kernel pointer by storing thisregister into a map.Using __mark_reg_not_init() while NOT allow_ptr_leaks can mitigate thisproblem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILEWhen using bpftool to pin {PROG, MAP, LINK} without FILE,segmentation fault will occur. The reson is that the lackof FILE will cause strlen to trigger NULL pointer dereference.The corresponding stacktrace is shown below:do_pin do_pin_any do_pin_fd mount_bpffs_for_pin strlen(name) <- NULL pointer dereferenceFix it by adding validation to the common process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, verifier: Fix memory leak in array reallocation for stack stateIf an error (NULL) is returned by krealloc(), callers of realloc_array()were setting their allocation pointers to NULL, but on error krealloc()does not touch the original allocation. This would result in a memoryresource leak. Instead, free the old allocation on the error handlingpath.The memory leak information is as follows as also reported by Zhengchao: unreferenced object 0xffff888019801800 (size 256): comm "bpf_repo", pid 6490, jiffies 4294959200 (age 17.170s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000b211474b>] __kmalloc_node_track_caller+0x45/0xc0 [<0000000086712a0b>] krealloc+0x83/0xd0 [<00000000139aab02>] realloc_array+0x82/0xe2 [<00000000b1ca41d1>] grow_stack_state+0xfb/0x186 [<00000000cd6f36d2>] check_mem_access.cold+0x141/0x1341 [<0000000081780455>] do_check_common+0x5358/0xb350 [<0000000015f6b091>] bpf_check.cold+0xc3/0x29d [<000000002973c690>] bpf_prog_load+0x13db/0x2240 [<00000000028d1644>] __sys_bpf+0x1605/0x4ce0 [<00000000053f29bd>] __x64_sys_bpf+0x75/0xb0 [<0000000056fedaf5>] do_syscall_64+0x35/0x80 [<000000002bd58261>] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix tree mod log mishandling of reallocated nodesWe have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009f R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000100c40 R12: 0000000000000001 R13: ffff8886c26d6a00 R14: ffff88829f5424f8 R15: ffff88877d831a00 FS: 00007fee1d80c780(0000) GS:ffff8890400c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fee1963a020 CR3: 0000000434f33002 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: btrfs_get_old_root+0x12b/0x420 btrfs_search_old_slot+0x64/0x2f0 ? tree_mod_log_oldest_root+0x3d/0xf0 resolve_indirect_ref+0xfd/0x660 ? ulist_alloc+0x31/0x60 ? kmem_cache_alloc_trace+0x114/0x2c0 find_parent_nodes+0x97a/0x17e0 ? ulist_alloc+0x30/0x60 btrfs_find_all_roots_safe+0x97/0x150 iterate_extent_inodes+0x154/0x370 ? btrfs_search_path_in_tree+0x240/0x240 iterate_inodes_from_logical+0x98/0xd0 ? btrfs_search_path_in_tree+0x240/0x240 btrfs_ioctl_logical_to_ino+0xd9/0x180 btrfs_ioctl+0xe2/0x2ec0 ? __mod_memcg_lruvec_state+0x3d/0x280 ? do_sys_openat2+0x6d/0x140 ? kretprobe_dispatcher+0x47/0x70 ? kretprobe_rethook_handler+0x38/0x50 ? rethook_trampoline_handler+0x82/0x140 ? arch_rethook_trampoline_callback+0x3b/0x50 ? kmem_cache_free+0xfb/0x270 ? do_sys_openat2+0xd5/0x140 __x64_sys_ioctl+0x71/0xb0 do_syscall_64+0x2d/0x40Which is this code in tree_mod_log_rewind() switch (tm->op) { case BTRFS_MOD_LOG_KEY_REMOVE_WHILE_FREEING: BUG_ON(tm->slot < n);This occurs because we replay the nodes in order that they happened, andwhen we do a REPLACE we will log a REMOVE_WHILE_FREEING for every slot,starting at 0. 'n' here is the number of items in this block, which inthis case was 1, but we had 2 REMOVE_WHILE_FREEING operations.The actual root cause of this was that we were replaying operations fora block that shouldn't have been replayed. Consider the followingsequence of events1. We have an already modified root, and we do a btrfs_get_tree_mod_seq().2. We begin removing items from this root, triggering KEY_REPLACE for it's child slots.3. We remove one of the 2 children this root node points to, thus triggering the root node promotion of the remaining child, and freeing this node.4. We modify a new root, and re-allocate the above node to the root node of this other root.The tree mod log looks something like this logical 0 op KEY_REPLACE (slot 1) seq 2 logical 0 op KEY_REMOVE (slot 1) seq 3 logical 0 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 4 logical 4096 op LOG_ROOT_REPLACE (old logical 0) seq 5 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 1) seq 6 logical 8192 op KEY_REMOVE_WHILE_FREEING (slot 0) seq 7 logical 0 op LOG_ROOT_REPLACE (old logical 8192) seq 8>From here the bug is triggered by the following steps1. Call btrfs_get_old_root() on the new_root.2. We call tree_mod_log_oldest_root(btrfs_root_node(new_root)), which is currently logical 0.3. tree_mod_log_oldest_root() calls tree_mod_log_search_oldest(), which gives us the KEY_REPLACE seq 2, and since that's not a LOG_ROOT_REPLACE we incorrectly believe that we don't have an old root, because we expect that the most recent change should be a LOG_ROOT_REPLACE.4. Back in tree_mod_log_oldest_root() we don't have a LOG_ROOT_REPLACE, so we don't set old_root, we simply use our e---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fscrypt: stop using keyrings subsystem for fscrypt_master_keyThe approach of fs/crypto/ internally managing the fscrypt_master_keystructs as the payloads of "struct key" objects contained in a"struct key" keyring has outlived its usefulness. The original idea wasto simplify the code by reusing code from the keyrings subsystem.However, several issues have arisen that can't easily be resolved:- When a master key struct is destroyed, blk_crypto_evict_key() must be called on any per-mode keys embedded in it. (This started being the case when inline encryption support was added.) Yet, the keyrings subsystem can arbitrarily delay the destruction of keys, even past the time the filesystem was unmounted. Therefore, currently there is no easy way to call blk_crypto_evict_key() when a master key is destroyed. Currently, this is worked around by holding an extra reference to the filesystem's request_queue(s). But it was overlooked that the request_queue reference is *not* guaranteed to pin the corresponding blk_crypto_profile too; for device-mapper devices that support inline crypto, it doesn't. This can cause a use-after-free.- When the last inode that was using an incompletely-removed master key is evicted, the master key removal is completed by removing the key struct from the keyring. Currently this is done via key_invalidate(). Yet, key_invalidate() takes the key semaphore. This can deadlock when called from the shrinker, since in fscrypt_ioctl_add_key(), memory is allocated with GFP_KERNEL under the same semaphore.- More generally, the fact that the keyrings subsystem can arbitrarily delay the destruction of keys (via garbage collection delay, or via random processes getting temporary key references) is undesirable, as it means we can't strictly guarantee that all secrets are ever wiped.- Doing the master key lookups via the keyrings subsystem results in the key_permission LSM hook being called. fscrypt doesn't want this, as all access control for encrypted files is designed to happen via the files themselves, like any other files. The workaround which SELinux users are using is to change their SELinux policy to grant key search access to all domains. This works, but it is an odd extra step that shouldn't really have to be done.The fix for all these issues is to change the implementation to what Ishould have done originally: don't use the keyrings subsystem to keeptrack of the filesystem's fscrypt_master_key structs. Instead, juststore them in a regular kernel data structure, and rework the referencecounting, locking, and lifetime accordingly. Retain support forRCU-mode key lookups by using a hash table. Replace fscrypt_sb_free()with fscrypt_sb_delete(), which releases the keys synchronously and runsa bit earlier during unmount, so that block devices are still available.A side effect of this patch is that neither the master keys themselvesnor the filesystem keyrings will be listed in /proc/keys anymore.("Master key users" and the master key users keyrings will still belisted.) However, this was mostly an implementation detail, and it wasintended just for debugging purposes. I don't know of anyone using it.This patch does *not* change how "master key users" (->mk_users) works;that still uses the keyrings subsystem. That is still needed for keyquotas, and changing that isn't necessary to solve the issues listedabove. If we decide to change that too, it would be a separate patch.I've marked this as fixing the original commit that added the fscryptkeyring, but as noted above the most important issue that this patchfixes wasn't introduced until the addition of inline encryption support.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: Fix kmemleak in blk_mq_init_allocated_queueThere is a kmemleak caused by modprobe null_blk.kounreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmalloc_node_trace+0x22/0x60 [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350 [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0 [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440 [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0 [<00000000b389383b>] do_init_module+0x1a4/0x680 [<0000000087cf3542>] load_module+0x6249/0x7110 [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200 [<00000000fdcfff51>] do_syscall_64+0x35/0x80 [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0That is because q->ma_ops is set to NULL before blk_release_queue iscalled.blk_mq_init_queue_data blk_mq_init_allocated_queue blk_mq_realloc_hw_ctxs for (i = 0; i < set->nr_hw_queues; i++) { old_hctx = xa_load(&q->hctx_table, i); if (!blk_mq_alloc_and_init_hctx(.., i, ..)) [1] if (!old_hctx) break; xa_for_each_start(&q->hctx_table, j, hctx, j) blk_mq_exit_hctx(q, set, hctx, j); [2] if (!q->nr_hw_queues) [3] goto err_hctxs; err_exit: q->mq_ops = NULL; [4] blk_put_queue blk_release_queue if (queue_is_mq(q)) [5] blk_mq_release(q);[1]: blk_mq_alloc_and_init_hctx failed at i != 0.[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list andwill be cleaned up in blk_mq_release.[3]: q->nr_hw_queues is 0.[4]: Set q->mq_ops to NULL.[5]: queue_is_mq returns false due to [4]. And blk_mq_releasewill not be called. The hctxs in q->unused_hctx_list are leaked.To fix it, call blk_release_queue in exception path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix WARNING in ip6_route_net_exit_late()During the initialization of ip6_route_net_init_late(), if fileipv6_route or rt6_stats fails to be created, the initialization issuccessful by default. Therefore, the ipv6_route or rt6_stats filedoesn't be found during the remove in ip6_route_net_exit_late(). Itwill cause WRNING.The following is the stack information:name 'rt6_stats'WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460PKRU: 55555554Call Trace:ops_exit_list+0xb0/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mdio: fix undefined behavior in bit shift for __mdiobus_registerShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c __mdiobus_register+0x49d/0x4e0 fixed_mdio_bus_init+0xd8/0x12d do_one_initcall+0x76/0x430 kernel_init_freeable+0x3b3/0x422 kernel_init+0x24/0x1e0 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: enforce documented limit to prevent allocating huge memoryDaniel Xu reported that the hash:net,iface type of the ipset subsystem doesnot limit adding the same network with different interfaces to a set, whichcan lead to huge memory usage or allocation failure.The quick reproducer is$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; doneThe backtrace when vmalloc fails: [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages <...> [Tue Oct 25 00:13:08 2022] Call Trace: [Tue Oct 25 00:13:08 2022] [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60 [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180 [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20 [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90 [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0 [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710 <...>The fix is to enforce the limit documented in the ipset(8) manpage:> The internal restriction of the hash:net,iface set type is that the same> network prefix cannot be stored with more than 64 different interfaces> in a single set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at find_parent_nodes()During backref walking, at find_parent_nodes(), if we are dealing with adata extent and we get an error while resolving the indirect backrefs, atresolve_indirect_refs(), or in the while loop that iterates over the refsin the direct refs rbtree, we end up leaking the inode lists attached tothe direct refs we have in the direct refs rbtree that were not yet addedto the refs ulist passed as argument to find_parent_nodes(). Since theywere not yet added to the refs ulist and prelim_release() does not freethe lists, on error the caller can only free the lists attached to therefs that were added to the refs ulist, all the remaining refs get theirinode lists never freed, therefore leaking their memory.Fix this by having prelim_release() always free any attached inode listto each ref found in the rbtree, and have find_parent_nodes() set theref's inode list to NULL once it transfers ownership of the inode listto a ref added to the refs ulist passed to find_parent_nodes().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix inode list leak during backref walking at resolve_indirect_refs()During backref walking, at resolve_indirect_refs(), if we get an errorwe jump to the 'out' label and call ulist_free() on the 'parents' ulist,which frees all the elements in the ulist - however that does not freeany inode lists that may be attached to elements, through the 'aux' fieldof a ulist node, so we end up leaking lists if we have any attached tothe unodes.Fix this by calling free_leaf_list() instead of ulist_free() when we exitfrom resolve_indirect_refs(). The static function free_leaf_list() ismoved up for this to be possible and it's slightly simplified by removingunnecessary code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix WARNING in ip_vs_app_net_cleanup()During the initialization of ip_vs_app_net_init(), if file ip_vs_appfails to be created, the initialization is successful by default.Therefore, the ip_vs_app file doesn't be found during the remove inip_vs_app_net_cleanup(). It will cause WRNING.The following is the stack information:name 'ip_vs_app'WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460Modules linked in:Workqueue: netns cleanup_netRIP: 0010:remove_proc_entry+0x389/0x460Call Trace:ops_exit_list+0x125/0x170cleanup_net+0x4ea/0xb00process_one_work+0x9bf/0x1710worker_thread+0x665/0x1080kthread+0x2e4/0x3a0ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: netlink notifier might race to release objectscommit release path is invoked via call_rcu and it runs lockless torelease the objects after rcu grace period. The netlink notifier handlermight win race to remove objects that the transaction context is stillreferencing from the commit release path.Call rcu_barrier() to ensure pending rcu callbacks run to completionif the list of transactions to be destroyed is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: Fix use after free in red_enqueue()We can't use "skb" again after passing it to qdisc_enqueue(). This isbasically identical to commit 2f09707d0c97 ("sch_sfb: Also store skblen before calling child enqueue").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49926 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: Fix possible memory leaks in dsa_loop_init()kmemleak reported memory leaks in dsa_loop_init():kmemleak: 12 new suspected memory leaksunreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 [<00000000a9c44622>] phy_device_create+0x5d/0x970 [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 [<000000008a834798>] fixed_phy_register+0x84/0xb0 [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] ...There are two reasons for memleak in dsa_loop_init().First, fixed_phy_register() create and register phy_device:fixed_phy_register() get_phy_device() phy_device_create() # freed by phy_device_free() phy_device_register() # freed by phy_device_remove()But fixed_phy_unregister() only calls phy_device_remove().So the memory allocated in phy_device_create() is leaked.Second, when mdio_driver_register() fail in dsa_loop_init(),it just returns and there is no cleanup for phydevs.Fix the problems by catching the error of mdio_driver_register()in dsa_loop_init(), then calling both fixed_phy_unregister() andphy_device_free() to release phydevs.Also add a function for phydevs cleanup to avoid duplacate.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/dma-resv: check if the new fence is really laterPreviously when we added a fence to a dma_resv object we alwaysassumed the the newer than all the existing fences.With Jason's work to add an UAPI to explicit export/import that's notnecessary the case any more. So without this check we would allowuserspace to force the kernel into an use after free error.Since the change is very small and defensive it's probably a goodidea to backport this to stable kernels as well just in case othersare using the dma_resv object in the same way.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a data-race around bpf_jit_limit.While reading bpf_jit_limit, it can be changed concurrently via sysctl,WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limitis long, so we need to add a paired READ_ONCE() to avoid load-tearing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Don't redirect packets with invalid pkt_lenSyzbot found an issue [1]: fq_codel_drop() try to drop a flow whitout anyskbs, that is, the flow->head is null.The root cause, as the [2] says, is because that bpf_prog_test_run_skb()run a bpf prog which redirects empty skbs.So we should determine whether the length of the packet modified by bpfprog or others like bpf_prog_test is valid before forwarding it directly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: avoid corrupting page->mapping in hugetlb_mcopy_atomic_pteIn MCOPY_ATOMIC_CONTINUE case with a non-shared VMA, pages in the pagecache are installed in the ptes. But hugepage_add_new_anon_rmap is calledfor them mistakenly because they're not vm_shared. This will corrupt thepage->mapping used by page cache code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bootmem: remove the vmemmap pages from kmemleak in put_page_bootmemThe vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reusethe page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6be00000 (size 335544320): kmemleak: comm "swapper", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lantiq_xrx200: restore buffer if memory allocation failedIn a situation where memory allocation fails, an invalid buffer addressis stored. When this descriptor is used again, the system panics in thebuild_skb() function when accessing memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix locking in rxrpc's sendmsgFix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/lock of the call mutex up to rxrpc_send_data() such that the lock is not held around all of rxrpc_wait_for_tx_window*() and (b) indicating to higher callers whether we're return with the lock dropped. Note that this means recvmsg() will not block on this call whilst we're waiting. (3) After dropping and regaining the call mutex, rxrpc_send_data() needs to go and recheck the state of the tx_pending buffer and the tx_total_len check in case we raced with another sendmsg() on the same call.Thinking on this some more, it might make sense to have different locks forsendmsg() and recvmsg(). There's probably no need to make recvmsg() waitfor sendmsg(). It does mean that recvmsg() can return MSG_EOR indicatingthat a call is dead before a sendmsg() to that call returns - but that cancurrently happen anyway.Without fix (2), something like the following can be induced: WARNING: bad unlock balance detected! 5.16.0-rc6-syzkaller #0 Not tainted ------------------------------------- syz-executor011/3597 is trying to release lock (&call->user_mutex) at: [] rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 but there are no more locks to release! other info that might help us debug this: no locks held by syz-executor011/3597. ... Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_unlock_imbalance_bug include/trace/events/lock.h:58 [inline] __lock_release kernel/locking/lockdep.c:5306 [inline] lock_release.cold+0x49/0x4e kernel/locking/lockdep.c:5657 __mutex_unlock_slowpath+0x99/0x5e0 kernel/locking/mutex.c:900 rxrpc_do_sendmsg+0xc13/0x1350 net/rxrpc/sendmsg.c:748 rxrpc_sendmsg+0x420/0x630 net/rxrpc/af_rxrpc.c:561 sock_sendmsg_nosec net/socket.c:704 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:724 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x44/0xae[Thanks to Hawkins Jiawei and Khalid Masum for their attempts to fix this]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: fix stuck flows on cleanup due to pending workTo clear the flow table on flow table free, the following sequencenormally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all entries from the flow table. 6) Flow table is freed.But if a flow table entry already has pending HW stats or HW add workstep 3 will not queue HW del work (it will be skipped), step 4 will waitfor the pending add/stats to finish, and step 5 will queue HW del workwhich might execute after freeing of the flow table.To fix the above, this patch flushes the pending work, then it sets theteardown flag to all flows in the flowtable and it forces a garbagecollector run to queue work to remove the flows from hardware, then itflushes this new pending work and (finally) it forces another garbagecollector run to remove the entry from the software flowtable.Stack trace:[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table][47773.889727] Call Trace:[47773.890214] dump_stack+0xbb/0x107[47773.890818] print_address_description.constprop.0+0x18/0x140[47773.892990] kasan_report.cold+0x7c/0xd8[47773.894459] kasan_check_range+0x145/0x1a0[47773.895174] down_read+0x99/0x460[47773.899706] nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table][47773.907137] flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table][47773.913372] process_one_work+0x8ac/0x14e0[47773.921325][47773.921325] Allocated by task 592159:[47773.922031] kasan_save_stack+0x1b/0x40[47773.922730] __kasan_kmalloc+0x7a/0x90[47773.923411] tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct][47773.924363] tcf_ct_init+0x71c/0x1156 [act_ct][47773.925207] tcf_action_init_1+0x45b/0x700[47773.925987] tcf_action_init+0x453/0x6b0[47773.926692] tcf_exts_validate+0x3d0/0x600[47773.927419] fl_change+0x757/0x4a51 [cls_flower][47773.928227] tc_new_tfilter+0x89a/0x2070[47773.936652][47773.936652] Freed by task 543704:[47773.937303] kasan_save_stack+0x1b/0x40[47773.938039] kasan_set_track+0x1c/0x30[47773.938731] kasan_set_free_info+0x20/0x30[47773.939467] __kasan_slab_free+0xe7/0x120[47773.940194] slab_free_freelist_hook+0x86/0x190[47773.941038] kfree+0xce/0x3a0[47773.941644] tcf_ct_flow_table_cleanup_workOriginal patch description and stack trace by Paul Blakey.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_tproxy: restrict to prerouting hookTPROXY is only allowed from prerouting, but nft_tproxy doesn't check this.This fixes a crash (null dereference) when using tproxy from e.g. output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READYOnly set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered.Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev andldev->pf[MLX5_LAG_P1].dev have valid pointers whenMLX5_LAG_FLAG_NDEVS_READY is set.The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY andclearing it. Setting it is done wrongly when bothldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev are set;clearing it is done right when either of ldev->pf[i].netdev is cleared.Consider the following scenario:1. PF0 loads and sets ldev->pf[MLX5_LAG_P0].dev to a valid pointer2. PF1 loads and sets both ldev->pf[MLX5_LAG_P1].dev and ldev->pf[MLX5_LAG_P1].netdev with valid pointers. This results in MLX5_LAG_FLAG_NDEVS_READY is set.3. PF0 is unloaded before setting dev->pf[MLX5_LAG_P0].netdev. MLX5_LAG_FLAG_NDEVS_READY remains set.Further execution of mlx5_do_bond() will result in null pointerdereference when calling mlx5_lag_is_multipath()This patch fixes the following call trace actually encountered:[ 1293.475195] BUG: kernel NULL pointer dereference, address: 00000000000009a8[ 1293.478756] #PF: supervisor read access in kernel mode[ 1293.481320] #PF: error_code(0x0000) - not-present page[ 1293.483686] PGD 0 P4D 0[ 1293.484434] Oops: 0000 [#1] SMP PTI[ 1293.485377] CPU: 1 PID: 23690 Comm: kworker/u16:2 Not tainted 5.18.0-rc5_for_upstream_min_debug_2022_05_05_10_13 #1[ 1293.488039] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 1293.490836] Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core][ 1293.492448] RIP: 0010:mlx5_lag_is_multipath+0x5/0x50 [mlx5_core][ 1293.494044] Code: e8 70 40 ff e0 48 8b 14 24 48 83 05 5c 1a 1b 00 01 e9 19 ff ff ff 48 83 05 47 1a 1b 00 01 eb d7 0f 1f 44 00 00 0f 1f 44 00 00 <48> 8b 87 a8 09 00 00 48 85 c0 74 26 48 83 05 a7 1b 1b 00 01 41 b8[ 1293.498673] RSP: 0018:ffff88811b2fbe40 EFLAGS: 00010202[ 1293.500152] RAX: ffff88818a94e1c0 RBX: ffff888165eca6c0 RCX: 0000000000000000[ 1293.501841] RDX: 0000000000000001 RSI: ffff88818a94e1c0 RDI: 0000000000000000[ 1293.503585] RBP: 0000000000000000 R08: ffff888119886740 R09: ffff888165eca73c[ 1293.505286] R10: 0000000000000018 R11: 0000000000000018 R12: ffff88818a94e1c0[ 1293.506979] R13: ffff888112729800 R14: 0000000000000000 R15: ffff888112729858[ 1293.508753] FS: 0000000000000000(0000) GS:ffff88852cc40000(0000) knlGS:0000000000000000[ 1293.510782] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1293.512265] CR2: 00000000000009a8 CR3: 00000001032d4002 CR4: 0000000000370ea0[ 1293.514001] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1293.515806] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: prohibit usage of non-balanced queue idFix the following scenario:1. ethtool -L $IFACE rx 8 tx 962. xdpsock -q 10 -t -zAbove refers to a case where user would like to attach XSK socket intxonly mode at a queue id that does not have a corresponding Rx queue.At this moment ice's XSK logic is tightly bound to act on a "queue pair",e.g. both Tx and Rx queues at a given queue id are disabled/enabled andboth of them will get XSK pool assigned, which is broken for the presentedqueue configuration. This results in the splat included at the bottom,which is basically an OOB access to Rx ring array.To fix this, allow using the ids only in scope of "combined" queuesreported by ethtool. However, logic should be rewritten to allow suchconfigurations later on, which would end up as a complete rewrite of thecontrol path, so let us go with this temporary fix.[420160.558008] BUG: kernel NULL pointer dereference, address: 0000000000000082[420160.566359] #PF: supervisor read access in kernel mode[420160.572657] #PF: error_code(0x0000) - not-present page[420160.579002] PGD 0 P4D 0[420160.582756] Oops: 0000 [#1] PREEMPT SMP NOPTI[420160.588396] CPU: 10 PID: 21232 Comm: xdpsock Tainted: G OE 5.19.0-rc7+ #10[420160.597893] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[420160.609894] RIP: 0010:ice_xsk_pool_setup+0x44/0x7d0 [ice][420160.616968] Code: f3 48 83 ec 40 48 8b 4f 20 48 8b 3f 65 48 8b 04 25 28 00 00 00 48 89 44 24 38 31 c0 48 8d 04 ed 00 00 00 00 48 01 c1 48 8b 11 <0f> b7 92 82 00 00 00 48 85 d2 0f 84 2d 75 00 00 48 8d 72 ff 48 85[420160.639421] RSP: 0018:ffffc9002d2afd48 EFLAGS: 00010282[420160.646650] RAX: 0000000000000050 RBX: ffff88811d8bdd00 RCX: ffff888112c14ff8[420160.655893] RDX: 0000000000000000 RSI: ffff88811d8bdd00 RDI: ffff888109861000[420160.665166] RBP: 000000000000000a R08: 000000000000000a R09: 0000000000000000[420160.674493] R10: 000000000000889f R11: 0000000000000000 R12: 000000000000000a[420160.683833] R13: 000000000000000a R14: 0000000000000000 R15: ffff888117611828[420160.693211] FS: 00007fa869fc1f80(0000) GS:ffff8897e0880000(0000) knlGS:0000000000000000[420160.703645] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[420160.711783] CR2: 0000000000000082 CR3: 00000001d076c001 CR4: 00000000007706e0[420160.721399] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[420160.731045] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[420160.740707] PKRU: 55555554[420160.745960] Call Trace:[420160.750962] [420160.755597] ? kmalloc_large_node+0x79/0x90[420160.762703] ? __kmalloc_node+0x3f5/0x4b0[420160.769341] xp_assign_dev+0xfd/0x210[420160.775661] ? shmem_file_read_iter+0x29a/0x420[420160.782896] xsk_bind+0x152/0x490[420160.788943] __sys_bind+0xd0/0x100[420160.795097] ? exit_to_user_mode_prepare+0x20/0x120[420160.802801] __x64_sys_bind+0x16/0x20[420160.809298] do_syscall_64+0x38/0x90[420160.815741] entry_SYSCALL_64_after_hwframe+0x63/0xcd[420160.823731] RIP: 0033:0x7fa86a0dd2fb[420160.830264] Code: c3 66 0f 1f 44 00 00 48 8b 15 69 8b 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bc 0f 1f 44 00 00 f3 0f 1e fa b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 3d 8b 0c 00 f7 d8 64 89 01 48[420160.855410] RSP: 002b:00007ffc1146f618 EFLAGS: 00000246 ORIG_RAX: 0000000000000031[420160.866366] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa86a0dd2fb[420160.876957] RDX: 0000000000000010 RSI: 00007ffc1146f680 RDI: 0000000000000003[420160.887604] RBP: 000055d7113a0520 R08: 00007fa868fb8000 R09: 0000000080000000[420160.898293] R10: 0000000000008001 R11: 0000000000000246 R12: 000055d7113a04e0[420160.909038] R13: 000055d7113a0320 R14: 000000000000000a R15: 0000000000000000[420160.919817] [420160.925659] Modules linked in: ice(OE) af_packet binfmt_misc---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix refcount leak in __xfrm_policy_check()The issue happens on an error path in __xfrm_policy_check(). When thefetching process of the object `pols[1]` fails, the function simplyreturns 0, forgetting to decrement the reference count of `pols[0]`,which is incremented earlier by either xfrm_sk_policy_lookup() orxfrm_policy_lookup(). This may result in memory leaks.Fix it by decreasing the reference count of `pols[0]` in that path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: cnl: Do not process IPC reply before firmware bootIt is not yet clear, but it is possible to create a firmware so brokenthat it will send a reply message before a FW_READY message (it is notyet clear if FW_READY will arrive later).Since the reply_data is allocated only after the FW_READY message, thiswill lead to a NULL pointer dereference if not filtered out.The issue was reported with IPC4 firmware but the same condition is presentfor IPC3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: genl: fix error path memory leak in policy dumpingIf construction of the array of policies fails when recordingnon-first policy we need to unwind.netlink_policy_dump_add_policy() itself also needs fixing asit currently gives up on error without recording the allocatedpointer in the pstate pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50043 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix potential refcount leak in ndisc_router_discovery()The issue happens on specific paths in the function. After both theobject `rt` and `neigh` are grabbed successfully, when `lifetime` isnonzero but the metric needs change, the function just deletes theroute and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`again if above conditions hold. The function simply overwrite `neigh`if succeeds or returns if fails, without decreasing the referencecount of previous `neigh`. This may result in memory leaks.Fix it by decrementing the reference count of `neigh` in place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: start MHI channel after endpoit creationMHI channel may generates event/interrupt right after enabling.It may leads to 2 race conditions issues.1)Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check: if (!qdev || mhi_res->transaction_status) return;Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed atthis moment. In this situation qrtr-ns will be unable to enumerateservices in device.---------------------------------------------------------------2)Such event may come at the moment after dev_set_drvdata() andbefore qrtr_endpoint_register(). In this case kernel will panic withaccessing wrong pointer at qcom_mhi_qrtr_dl_callback(): rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr, mhi_res->bytes_xferd);Because endpoint is not created yet.--------------------------------------------------------------So move mhi_prepare_for_transfer_autoqueue after endpoint creationto fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: possible module reference underflow in error pathdst->ops is set on when nft_expr_clone() fails, but module refcount hasnot been bumped yet, therefore nft_expr_destroy() leads to modulereference underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()snprintf() returns the would-be-filled size when the string overflowsthe given buffer size, hence using this value may result in the bufferoverflow (although it's unrealistic).This patch replaces with a safer version, scnprintf() for paperingover such a potential issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:BPF: Fix potential bad pointer dereference in bpf_sys_bpf()The bpf_sys_bpf() helper function allows an eBPF program to load anothereBPF program from within the kernel. In this case the argument unionbpf_attr pointer (as well as the insns and license pointers inside) is akernel address instead of a userspace address (which is the case of ausual bpf() syscall). To make the memory copying process in the syscallwork in both cases, bpfptr_t was introduced to wrap around the pointerand distinguish its origin. Specifically, when copying memory contentsfrom a bpfptr_t, a copy_from_user() is performed in case of a userspaceaddress and a memcpy() is performed for a kernel address.This can lead to problems because the in-kernel pointer is never checkedfor validity. The problem happens when an eBPF syscall program tries tocall bpf_sys_bpf() to load a program but provides a bad insns pointer --say 0xdeadbeef -- in the bpf_attr union. The helper calls __sys_bpf()which would then call bpf_prog_load() to load the program.bpf_prog_load() is responsible for copying the eBPF instructions to thenewly allocated memory for the program; it creates a kernel bpfptr_t forinsns and invokes copy_from_bpfptr(). Internally, all bpfptr_toperations are backed by the corresponding sockptr_t operations, whichperforms direct memcpy() on kernel pointers for copy_from/strncpy_fromoperations. Therefore, the code is always happy to dereference the badpointer to trigger a un-handle-able page fault and in turn an oops.However, this is not supposed to happen because at that point the eBPFprogram is already verified and should not cause a memory error.Sample KASAN trace:[ 25.685056][ T228] ==================================================================[ 25.685680][ T228] BUG: KASAN: user-memory-access in copy_from_bpfptr+0x21/0x30[ 25.686210][ T228] Read of size 80 at addr 00000000deadbeef by task poc/228[ 25.686732][ T228][ 25.686893][ T228] CPU: 3 PID: 228 Comm: poc Not tainted 5.19.0-rc7 #7[ 25.687375][ T228] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014[ 25.687991][ T228] Call Trace:[ 25.688223][ T228] [ 25.688429][ T228] dump_stack_lvl+0x73/0x9e[ 25.688747][ T228] print_report+0xea/0x200[ 25.689061][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.689401][ T228] ? _printk+0x54/0x6e[ 25.689693][ T228] ? _raw_spin_lock_irqsave+0x70/0xd0[ 25.690071][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.690412][ T228] kasan_report+0xb5/0xe0[ 25.690716][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691059][ T228] kasan_check_range+0x2bd/0x2e0[ 25.691405][ T228] ? copy_from_bpfptr+0x21/0x30[ 25.691734][ T228] memcpy+0x25/0x60[ 25.692000][ T228] copy_from_bpfptr+0x21/0x30[ 25.692328][ T228] bpf_prog_load+0x604/0x9e0[ 25.692653][ T228] ? cap_capable+0xb4/0xe0[ 25.692956][ T228] ? security_capable+0x4f/0x70[ 25.693324][ T228] __sys_bpf+0x3af/0x580[ 25.693635][ T228] bpf_sys_bpf+0x45/0x240[ 25.693937][ T228] bpf_prog_f0ec79a5a3caca46_bpf_func1+0xa2/0xbd[ 25.694394][ T228] bpf_prog_run_pin_on_cpu+0x2f/0xb0[ 25.694756][ T228] bpf_prog_test_run_syscall+0x146/0x1c0[ 25.695144][ T228] bpf_prog_test_run+0x172/0x190[ 25.695487][ T228] __sys_bpf+0x2c5/0x580[ 25.695776][ T228] __x64_sys_bpf+0x3a/0x50[ 25.696084][ T228] do_syscall_64+0x60/0x90[ 25.696393][ T228] ? fpregs_assert_state_consistent+0x50/0x60[ 25.696815][ T228] ? exit_to_user_mode_prepare+0x36/0xa0[ 25.697202][ T228] ? syscall_exit_to_user_mode+0x20/0x40[ 25.697586][ T228] ? do_syscall_64+0x6e/0x90[ 25.697899][ T228] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 25.698312][ T228] RIP: 0033:0x7f6d543fb759[ 25.698624][ T228] Code: 08 5b 89 e8 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: do not queue data on closed subflowsDipanjan reported a syzbot splat at close time:WARNING: CPU: 1 PID: 10818 at net/ipv4/af_inet.c:153inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Modules linked in: uio_ivshmem(OE) uio(E)CPU: 1 PID: 10818 Comm: kworker/1:16 Tainted: G OE5.19.0-rc6-g2eae0556bb9d #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Workqueue: events mptcp_workerRIP: 0010:inet_sock_destruct+0x6d0/0x8e0 net/ipv4/af_inet.c:153Code: 21 02 00 00 41 8b 9c 24 28 02 00 00 e9 07 ff ff ff e8 34 4d 91f9 89 ee 4c 89 e7 e8 4a 47 60 ff e9 a6 fc ff ff e8 20 4d 91 f9 <0f> 0be9 84 fe ff ff e8 14 4d 91 f9 0f 0b e9 d4 fd ff ff e8 08 4dRSP: 0018:ffffc9001b35fa78 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002879d0 RCX: ffff8881326f3b00RDX: 0000000000000000 RSI: ffff8881326f3b00 RDI: 0000000000000002RBP: ffff888179662674 R08: ffffffff87e983a0 R09: 0000000000000000R10: 0000000000000005 R11: 00000000000004ea R12: ffff888179662400R13: ffff888179662428 R14: 0000000000000001 R15: ffff88817e38e258FS: 0000000000000000(0000) GS:ffff8881f5f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020007bc0 CR3: 0000000179592000 CR4: 0000000000150ee0Call Trace: __sk_destruct+0x4f/0x8e0 net/core/sock.c:2067 sk_destruct+0xbd/0xe0 net/core/sock.c:2112 __sk_free+0xef/0x3d0 net/core/sock.c:2123 sk_free+0x78/0xa0 net/core/sock.c:2134 sock_put include/net/sock.h:1927 [inline] __mptcp_close_ssk+0x50f/0x780 net/mptcp/protocol.c:2351 __mptcp_destroy_sock+0x332/0x760 net/mptcp/protocol.c:2828 mptcp_worker+0x5d2/0xc90 net/mptcp/protocol.c:2586 process_one_work+0x9cc/0x1650 kernel/workqueue.c:2289 worker_thread+0x623/0x1070 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 The root cause of the problem is that an mptcp-level (re)transmit canrace with mptcp_close() and the packet scheduler checks the subflowstate before acquiring the socket lock: we can try to (re)transmit onan already closed ssk.Fix the issue checking again the subflow socket status under thesubflow socket lock protection. Additionally add the missing checkfor the fallback-to-tcp case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: move subflow cleanup in mptcp_destroy_common()If the mptcp socket creation fails due to a CGROUP_INET_SOCK_CREATEeBPF program, the MPTCP protocol ends-up leaking all the subflows:the related cleanup happens in __mptcp_destroy_sock() that is notinvoked in such code path.Address the issue moving the subflow sockets cleanup in themptcp_destroy_common() helper, which is invoked in every msk cleanuppath.Additionally get rid of the intermediate list_splice_init step, whichis an unneeded relic from the past.The issue is present since before the reported root cause commit, butany attempt to backport the fix before that hash will require a completerewrite.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: add overflow check in register_shm_helper()With special lengths supplied by user space, register_shm_helper() hasan integer overflow when calculating the number of pages covered by asupplied user space memory region.This causes internal_get_user_pages_fast() a helper function ofpin_user_pages_fast() to do a NULL pointer dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: optee_example_a Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internal_get_user_pages_fast+0x474/0xa80 Call trace: internal_get_user_pages_fast+0x474/0xa80 pin_user_pages_fast+0x24/0x4c register_shm_helper+0x194/0x330 tee_shm_register_user_buf+0x78/0x120 tee_ioctl+0xd0/0x11a0 __arm64_sys_ioctl+0xa8/0xec invoke_syscall+0x48/0x114Fix this by adding an an explicit call to access_ok() intee_shm_register_user_buf() to catch an invalid user space addressearly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix warning in ext4_iomap_begin as race between bmap and writeWe got issue as follows:------------[ cut here ]------------WARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0RIP: 0010:ext4_iomap_begin+0x182/0x5d0RSP: 0018:ffff88812460fa08 EFLAGS: 00010293RAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20fR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001R13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691eeFS: 00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: iomap_apply+0x119/0x570 iomap_bmap+0x124/0x150 ext4_bmap+0x14f/0x250 bmap+0x55/0x80 do_vfs_ioctl+0x952/0xbd0 __x64_sys_ioctl+0xc6/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xa9Above issue may happen as follows: bmap writebmap ext4_bmap iomap_bmap ext4_iomap_begin ext4_file_write_iter ext4_buffered_write_iter generic_perform_write ext4_da_write_begin ext4_da_write_inline_data_begin ext4_prepare_inline_data ext4_create_inline_data ext4_set_inode_flag(inode, EXT4_INODE_INLINE_DATA); if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_onTo solved above issue hold inode lock in ext4_bamp.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: don't allow the same type rq_qos add more than onceIn our test of iocost, we encountered some list add/del corruptions ofinner_walk list in ioc_timer_fn.The reason can be described as follows:cpu 0 cpu 1ioc_qos_write ioc_qos_writeioc = q_to_ioc(queue);if (!ioc) { ioc = kzalloc(); ioc = q_to_ioc(queue); if (!ioc) { ioc = kzalloc(); ... rq_qos_add(q, rqos); } ... rq_qos_add(q, rqos); ...}When the io.cost.qos file is written by two cpus concurrently, rq_qos maybe added to one disk twice. In that case, there will be two iocs enabledand running on one disk. They own different iocgs on their active list. Inthe ioc_timer_fn function, because of the iocgs from two iocs have thesame root iocg, the root iocg's walk_list may be overwritten by each otherand this leads to list add/del corruptions in building or destroying theinner_walk list.And so far, the blk-rq-qos framework works in case that one instance forone type rq_qos per queue by default. This patch make this explicit andalso fix the crash above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ensure pages are unlocked on cow_file_range() failureThere is a hung_task report on zoned btrfs like below.https://github.com/naota/linux/issues/59 [726.328648] INFO: task rocksdb:high0:11085 blocked for more than 241 seconds. [726.329839] Not tainted 5.16.0-rc1+ #1 [726.330484] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [726.331603] task:rocksdb:high0 state:D stack: 0 pid:11085 ppid: 11082 flags:0x00000000 [726.331608] Call Trace: [726.331611] [726.331614] __schedule+0x2e5/0x9d0 [726.331622] schedule+0x58/0xd0 [726.331626] io_schedule+0x3f/0x70 [726.331629] __folio_lock+0x125/0x200 [726.331634] ? find_get_entries+0x1bc/0x240 [726.331638] ? filemap_invalidate_unlock_two+0x40/0x40 [726.331642] truncate_inode_pages_range+0x5b2/0x770 [726.331649] truncate_inode_pages_final+0x44/0x50 [726.331653] btrfs_evict_inode+0x67/0x480 [726.331658] evict+0xd0/0x180 [726.331661] iput+0x13f/0x200 [726.331664] do_unlinkat+0x1c0/0x2b0 [726.331668] __x64_sys_unlink+0x23/0x30 [726.331670] do_syscall_64+0x3b/0xc0 [726.331674] entry_SYSCALL_64_after_hwframe+0x44/0xae [726.331677] RIP: 0033:0x7fb9490a171b [726.331681] RSP: 002b:00007fb943ffac68 EFLAGS: 00000246 ORIG_RAX: 0000000000000057 [726.331684] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9490a171b [726.331686] RDX: 00007fb943ffb040 RSI: 000055a6bbe6ec20 RDI: 00007fb94400d300 [726.331687] RBP: 00007fb943ffad00 R08: 0000000000000000 R09: 0000000000000000 [726.331688] R10: 0000000000000031 R11: 0000000000000246 R12: 00007fb943ffb000 [726.331690] R13: 00007fb943ffb040 R14: 0000000000000000 R15: 00007fb943ffd260 [726.331693] While we debug the issue, we found running fstests generic/551 on 5GBnon-zoned null_blk device in the emulated zoned mode also had asimilar hung issue.Also, we can reproduce the same symptom with an error injectedcow_file_range() setup.The hang occurs when cow_file_range() fails in the middle ofallocation. cow_file_range() called from do_allocation_zoned() cansplit the give region ([start, end]) for allocation depending oncurrent block group usages. When btrfs can allocate bytes for one partof the split regions but fails for the other region (e.g. because of-ENOSPC), we return the error leaving the pages in the succeeded regionslocked. Technically, this occurs only when @unlock == 0. Otherwise, weunlock the pages in an allocated region after creating an orderedextent.Considering the callers of cow_file_range(unlock=0) won't write outthe pages, we can unlock the pages on error exit fromcow_file_range(). So, we can ensure all the pages except @locked_pageare unlocked on error case.In summary, cow_file_range now behaves like this:- page_started == 1 (return value) - All the pages are unlocked. IO is started.- unlock == 1 - All the pages except @locked_page are unlocked in any case- unlock == 0 - On success, all the pages are locked for writing out them - On failure, all the pages except @locked_page are unlocked

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BTRFS_MAX_EXTENT_SIZE with fs_info->max_extent_sizeOn zoned filesystem, data write out is limited by max_zone_append_size,and a large ordered extent is split according the size of a bio. OTOH,the number of extents to be written is calculated usingBTRFS_MAX_EXTENT_SIZE, and that estimated number is used to reserve themetadata bytes to update and/or create the metadata items.The metadata reservation is done at e.g, btrfs_buffered_write() and thenreleased according to the estimation changes. Thus, if the number of extentincreases massively, the reserved metadata can run out.The increase of the number of extents easily occurs on zoned filesystemif BTRFS_MAX_EXTENT_SIZE > max_zone_append_size. And, it causes thefollowing warning on a small RAM environment with disabling metadataover-commit (in the following patch).[75721.498492] ------------[ cut here ]------------[75721.505624] BTRFS: block rsv 1 returned -28[75721.512230] WARNING: CPU: 24 PID: 2327559 at fs/btrfs/block-rsv.c:537 btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.581854] CPU: 24 PID: 2327559 Comm: kworker/u64:10 Kdump: loaded Tainted: G W 5.18.0-rc2-BTRFS-ZNS+ #109[75721.597200] Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021[75721.607310] Workqueue: btrfs-endio-write btrfs_work_helper [btrfs][75721.616209] RIP: 0010:btrfs_use_block_rsv+0x560/0x760 [btrfs][75721.646649] RSP: 0018:ffffc9000fbdf3e0 EFLAGS: 00010286[75721.654126] RAX: 0000000000000000 RBX: 0000000000004000 RCX: 0000000000000000[75721.663524] RDX: 0000000000000004 RSI: 0000000000000008 RDI: fffff52001f7be6e[75721.672921] RBP: ffffc9000fbdf420 R08: 0000000000000001 R09: ffff889f8d1fc6c7[75721.682493] R10: ffffed13f1a3f8d8 R11: 0000000000000001 R12: ffff88980a3c0e28[75721.692284] R13: ffff889b66590000 R14: ffff88980a3c0e40 R15: ffff88980a3c0e8a[75721.701878] FS: 0000000000000000(0000) GS:ffff889f8d000000(0000) knlGS:0000000000000000[75721.712601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[75721.720726] CR2: 000055d12e05c018 CR3: 0000800193594000 CR4: 0000000000350ee0[75721.730499] Call Trace:[75721.735166] [75721.739886] btrfs_alloc_tree_block+0x1e1/0x1100 [btrfs][75721.747545] ? btrfs_alloc_logged_file_extent+0x550/0x550 [btrfs][75721.756145] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.762852] ? btrfs_get_32+0xea/0x2d0 [btrfs][75721.769520] ? push_leaf_left+0x420/0x620 [btrfs][75721.776431] ? memcpy+0x4e/0x60[75721.781931] split_leaf+0x433/0x12d0 [btrfs][75721.788392] ? btrfs_get_token_32+0x580/0x580 [btrfs][75721.795636] ? push_for_double_split.isra.0+0x420/0x420 [btrfs][75721.803759] ? leaf_space_used+0x15d/0x1a0 [btrfs][75721.811156] btrfs_search_slot+0x1bc3/0x2790 [btrfs][75721.818300] ? lock_downgrade+0x7c0/0x7c0[75721.824411] ? free_extent_buffer.part.0+0x107/0x200 [btrfs][75721.832456] ? split_leaf+0x12d0/0x12d0 [btrfs][75721.839149] ? free_extent_buffer.part.0+0x14f/0x200 [btrfs][75721.846945] ? free_extent_buffer+0x13/0x20 [btrfs][75721.853960] ? btrfs_release_path+0x4b/0x190 [btrfs][75721.861429] btrfs_csum_file_blocks+0x85c/0x1500 [btrfs][75721.869313] ? rcu_read_lock_sched_held+0x16/0x80[75721.876085] ? lock_release+0x552/0xf80[75721.881957] ? btrfs_del_csums+0x8c0/0x8c0 [btrfs][75721.888886] ? __kasan_check_write+0x14/0x20[75721.895152] ? do_raw_read_unlock+0x44/0x80[75721.901323] ? _raw_write_lock_irq+0x60/0x80[75721.907983] ? btrfs_global_root+0xb9/0xe0 [btrfs][75721.915166] ? btrfs_csum_root+0x12b/0x180 [btrfs][75721.921918] ? btrfs_get_global_root+0x820/0x820 [btrfs][75721.929166] ? _raw_write_unlock+0x23/0x40[75721.935116] ? unpin_extent_cache+0x1e3/0x390 [btrfs][75721.942041] btrfs_finish_ordered_io.isra.0+0xa0c/0x1dc0 [btrfs][75721.949906] ? try_to_wake_up+0x30/0x14a0[75721.955700] ? btrfs_unlink_subvol+0xda0/0xda0 [btrfs][75721.962661] ? rcu---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50091 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:locking/csd_lock: Change csdlock_debug from early_param to __setupThe csdlock_debug kernel-boot parameter is parsed by theearly_param() function csdlock_debug(). If set, csdlock_debug()invokes static_branch_enable() to enable csd_lock_wait feature, whichtriggers a panic on arm64 for kernels built with CONFIG_SPARSEMEM=y andCONFIG_SPARSEMEM_VMEMMAP=n.With CONFIG_SPARSEMEM_VMEMMAP=n, __nr_to_section is called instatic_key_enable() and returns NULL, resulting in a NULL dereferencebecause mem_section is initialized only later in sparse_init().This is also a problem for powerpc because early_param() functionsare invoked earlier than jump_label_init(), also resulting instatic_key_enable() failures. These failures cause the warning "statickey 'xxx' used before call to jump_label_init()".Thus, early_param is too early for csd_lock_wait to runstatic_branch_enable(), so changes it to __setup to fix these.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/kprobes: Update kcb status flag after singlesteppingFix kprobes to update kcb (kprobes control block) status flag toKPROBE_HIT_SSDONE even if the kp->post_handler is not set.This bug may cause a kernel panic if another INT3 user runs rightafter kprobes because kprobe_int3_handler() misunderstands theINT3 is kprobe's single stepping INT3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: 9p: fix refcount leak in p9_read_work() error handlingp9_req_put need to be called when m->rreq->rc.sdata is NULL to avoidtemporary refcount leak.[Dominique: commit wording adjustments, p9_req_put argument fixes for rebase]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: revisit driver bind/unbind and callbacksIn the SoundWire probe, we store a pointer from the driver ops intothe 'slave' structure. This can lead to kernel oopses when unbindingcodec drivers, e.g. with the following sequence to remove machinedriver and codec driver./sbin/modprobe -r snd_soc_sof_sdw/sbin/modprobe -r snd_soc_rt711The full details can be found in the BugLink below, for reference thetwo following examples show different cases of driver ops/callbacksbeing invoked after the driver .remove().kernel: BUG: kernel NULL pointer dereference, address: 0000000000000150kernel: Workqueue: events cdns_update_slave_status_work [soundwire_cadence]kernel: RIP: 0010:mutex_lock+0x19/0x30kernel: Call Trace:kernel: ? sdw_handle_slave_status+0x426/0xe00 [soundwire_bus 94ff184bf398570c3f8ff7efe9e32529f532e4ae]kernel: ? newidle_balance+0x26a/0x400kernel: ? cdns_update_slave_status_work+0x1e9/0x200 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: BUG: unable to handle page fault for address: ffffffffc07654c8kernel: Workqueue: pm pm_runtime_workkernel: RIP: 0010:sdw_bus_prep_clk_stop+0x6f/0x160 [soundwire_bus]kernel: Call Trace:kernel: kernel: sdw_cdns_clock_stop+0xb5/0x1b0 [soundwire_cadence 1bcf98eebe5ba9833cd433323769ac923c9c6f82]kernel: intel_suspend_runtime+0x5f/0x120 [soundwire_intel aca858f7c87048d3152a4a41bb68abb9b663a1dd]kernel: ? dpm_sysfs_remove+0x60/0x60This was not detected earlier in Intel tests since the tests firstremove the parent PCI device and shut down the bus. The sequenceabove is a corner case which keeps the bus operational but without adriver bound.While trying to solve this kernel oopses, it became clear that theexisting SoundWire bus does not deal well with the unbind case.Commit 528be501b7d4a ("soundwire: sdw_slave: add probe_complete structure and new fields")added a 'probed' status variable and a 'probe_complete'struct completion. This status is however not reset on remove andlikewise the 'probe complete' is not re-initialized, so thebind/unbind/bind test cases would fail. The timeout used before the'update_status' callback was also a bad idea in hindsight, thereshould really be no timing assumption as to if and when a driver isbound to a device.An initial draft was based on device_lock() and device_unlock() wastested. This proved too complicated, with deadlocks created during thesuspend-resume sequences, which also use the same device_lock/unlock()as the bind/unbind sequences. On a CometLake device, a bad DSDT/BIOScaused spurious resumes and the use of device_lock() caused hangsduring suspend. After multiple weeks or testing and painfulreverse-engineering of deadlocks on different devices, we looked foralternatives that did not interfere with the device core.A bus notifier was used successfully to keep track of DRIVER_BOUND andDRIVER_UNBIND events. This solved the bind-unbind-bind case in tests,but it can still be defeated with a theoretical corner case where thememory is freed by a .remove while the callback is in use. Thenotifier only helps make sure the driver callbacks are valid, but notthat the memory allocated in probe remains valid while the callbacksare invoked.This patch suggests the introduction of a new 'sdw_dev_lock' mutexprotecting probe/remove and all driver callbacks. Since this mutex is'local' to SoundWire only, it does not interfere with existing locksand does not create deadlocks. In addition, this patch removes the'probe_complete' completion, instead we directly invoke the'update_status' from the probe routine. That removes any sort oftiming dependency and a much better support for the device/drivermodel, the driver could be bound before the bus started, or eons afterthe bus started and the hardware would be properly initialized in allcases.BugLink: https://github.com/thesofproject/linux/is---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50159 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: check previous kernel's ima-kexec-buffer against memory boundsPresently ima_get_kexec_buffer() doesn't check if the previous kernel'sima-kexec-buffer lies outside the addressable memory range. This can resultin a kernel panic if the new kernel is booted with 'mem=X' arg and theima-kexec-buffer was allocated beyond that range by the previous kernel.The panic is usually of the form below:$ sudo kexec --initrd initrd vmlinux --append='mem=16G' BUG: Unable to handle kernel data access on read at 0xc000c01fff7f0000 Faulting instruction address: 0xc000000000837974 Oops: Kernel access of bad area, sig: 11 [#1] NIP [c000000000837974] ima_restore_measurement_list+0x94/0x6c0 LR [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 Call Trace: [c00000000371fa80] [c00000000083b55c] ima_load_kexec_buffer+0xac/0x160 [c00000000371fb00] [c0000000020512c4] ima_init+0x80/0x108 [c00000000371fb70] [c0000000020514dc] init_ima+0x4c/0x120 [c00000000371fbf0] [c000000000012240] do_one_initcall+0x60/0x2c0 [c00000000371fcc0] [c000000002004ad0] kernel_init_freeable+0x344/0x3ec [c00000000371fda0] [c0000000000128a4] kernel_init+0x34/0x1b0 [c00000000371fe10] [c00000000000ce64] ret_from_kernel_thread+0x5c/0x64 Instruction dump: f92100b8 f92100c0 90e10090 910100a0 4182050c 282a0017 3bc00000 40810330 7c0802a6 fb610198 7c9b2378 f80101d0 2c090001 40820614 e9240010 ---[ end trace 0000000000000000 ]---Fix this issue by checking returned PFN range of previous kernel'sima-kexec-buffer with page_is_ram() to ensure correct memory bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix incorrect dev_tracker usageWhile investigating a separate rose issue [1], and enablingCONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]An ax25_dev can be used by one (or many) struct ax25_cb.We thus need different dev_tracker, one per struct ax25_cb.After this patch is applied, we are able to focus on rose.[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/[2][ 205.798723] reference already released.[ 205.798732] allocated in:[ 205.798734] ax25_bind+0x1a2/0x230 [ax25][ 205.798747] __sys_bind+0xea/0x110[ 205.798753] __x64_sys_bind+0x18/0x20[ 205.798758] do_syscall_64+0x5c/0x80[ 205.798763] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798768] freed in:[ 205.798770] ax25_release+0x115/0x370 [ax25][ 205.798778] __sock_release+0x42/0xb0[ 205.798782] sock_close+0x15/0x20[ 205.798785] __fput+0x9f/0x260[ 205.798789] ____fput+0xe/0x10[ 205.798792] task_work_run+0x64/0xa0[ 205.798798] exit_to_user_mode_prepare+0x18b/0x190[ 205.798804] syscall_exit_to_user_mode+0x26/0x40[ 205.798808] do_syscall_64+0x69/0x80[ 205.798812] entry_SYSCALL_64_after_hwframe+0x44/0xae[ 205.798827] ------------[ cut here ]------------[ 205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81[ 205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video[ 205.798948] mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25][ 205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3[ 205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020[ 205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81[ 205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e[ 205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286[ 205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000[ 205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff[ 205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618[ 205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0[ 205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001[ 205.799024] FS: 0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000[ 205.799028] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0[ 205.799033] Call Trace:[ 205.799035] [ 205.799038] ? ax25_dev_device_down+0xd9/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: When HCI work queue is drained, only queue chained workThe HCI command, event, and data packet processing workqueue is drainedto avoid deadlock in commit76727c02c1e1 ("Bluetooth: Call drain_workqueue() before resetting state").There is another delayed work, which will queue command to this drainedworkqueue. Which results in the following error report:Bluetooth: hci2: command 0x040f tx timeoutWARNING: CPU: 1 PID: 18374 at kernel/workqueue.c:1438 __queue_work+0xdad/0x1140Workqueue: events hci_cmd_timeoutRIP: 0010:__queue_work+0xdad/0x1140RSP: 0000:ffffc90002cffc60 EFLAGS: 00010093RAX: 0000000000000000 RBX: ffff8880b9d3ec00 RCX: 0000000000000000RDX: ffff888024ba0000 RSI: ffffffff814e048d RDI: ffff8880b9d3ec08RBP: 0000000000000008 R08: 0000000000000000 R09: 00000000b9d39700R10: ffffffff814f73c6 R11: 0000000000000000 R12: ffff88807cce4c60R13: 0000000000000000 R14: ffff8880796d8800 R15: ffff8880796d8800FS: 0000000000000000(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000c0174b4000 CR3: 000000007cae9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? queue_work_on+0xcb/0x110 ? lockdep_hardirqs_off+0x90/0xd0 queue_work_on+0xee/0x110 process_one_work+0x996/0x1610 ? pwq_dec_nr_in_flight+0x2a0/0x2a0 ? rwlock_bug.part.0+0x90/0x90 ? _raw_spin_lock_irq+0x41/0x50 worker_thread+0x665/0x1080 ? process_one_work+0x1610/0x1610 kthread+0x2e9/0x3a0 ? kthread_complete_and_exit+0x40/0x40 ret_from_fork+0x1f/0x30 To fix this, we can add a new HCI_DRAIN_WQ flag, and don't queue thetimeout workqueue while command workqueue is draining.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix potential 32-bit overflow when accessing ARRAY map elementIf BPF array map is bigger than 4GB, element pointer calculation canoverflow because both index and elem_size are u32. Fix this everywhereby forcing 64-bit multiplication. Extract this formula into separatesmall helper and use it consistently in various places.Speculative-preventing formula utilizing index_mask trick is left as is,but explicit u64 casts are added in both places.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: avoid kernel hung in hinic_get_stats64()When using hinic device as a bond slave device, and reading device statsof master bond device, the kernel may hung.The kernel panic calltrace as follows:Kernel panic - not syncing: softlockup: hung tasksCall trace: native_queued_spin_lock_slowpath+0x1ec/0x31c dev_get_stats+0x60/0xcc dev_seq_printf_stats+0x40/0x120 dev_seq_show+0x1c/0x40 seq_read_iter+0x3c8/0x4dc seq_read+0xe0/0x130 proc_reg_read+0xa8/0xe0 vfs_read+0xb0/0x1d4 ksys_read+0x70/0xfc __arm64_sys_read+0x20/0x30 el0_svc_common+0x88/0x234 do_el0_svc+0x2c/0x90 el0_svc+0x1c/0x30 el0_sync_handler+0xa8/0xb0 el0_sync+0x148/0x180And the calltrace of task that actually caused kernel hungs as follows: __switch_to+124 __schedule+548 schedule+72 schedule_timeout+348 __down_common+188 __down+24 down+104 hinic_get_stats64+44 [hinic] dev_get_stats+92 bond_get_stats+172 [bonding] dev_get_stats+92 dev_seq_printf_stats+60 dev_seq_show+24 seq_read_iter+964 seq_read+220 proc_reg_read+164 vfs_read+172 ksys_read+108 __arm64_sys_read+28 el0_svc_common+132 do_el0_svc+40 el0_svc+24 el0_sync_handler+164 el0_sync+324When getting device stats from bond, kernel will call bond_get_stats().It first holds the spinlock bond->stats_lock, and then callhinic_get_stats64() to collect hinic device's stats.However, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` toprotect its critical section, which may schedule current task out.And if system is under high pressure, the task cannot be woken upimmediately, which eventually triggers kernel hung panic.Since previous patch has replaced hinic_dev.tx_stats/rx_stats with localvariable in hinic_get_stats64(), there is nothing need to be protectedby lock, so just removing down()/up() is ok.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50177 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcutorture: Fix ksoftirqd boosting timing and iterationThe RCU priority boosting can fail in two situations:1) If (nr_cpus= > maxcpus=), which means if the total number of CPUsis higher than those brought online at boot, then torture_onoff() maylater bring up CPUs that weren't online on boot. Now since rcutortureinitialization only boosts the ksoftirqds of the CPUs that have beenset online on boot, the CPUs later set online by torture_onoff won'tbenefit from the boost, making RCU priority boosting fail.2) The ksoftirqd kthreads are boosted after the creation ofrcu_torture_boost() kthreads, which opens a window large enough for thesercu_torture_boost() kthreads to wait (despite running at FIFO priority)for ksoftirqds that are still running at SCHED_NORMAL priority.The issues can trigger for example with: ./kvm.sh --configs TREE01 --kconfig "CONFIG_RCU_BOOST=y" [ 34.968561] rcu-torture: !!! [ 34.968627] ------------[ cut here ]------------ [ 35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610 [ 35.052043] Modules linked in: [ 35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1 [ 35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014 [ 35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610 [ 35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82 [ 37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202 [ 37.277320] rcu: De-offloading 8 [ 37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001 [ 37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff [ 37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff [ 37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20 [ 37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0 [ 37.290427] FS: 0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000 [ 37.290448] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0 [ 37.290470] Call Trace: [ 37.295049] [ 37.295065] ? preempt_count_add+0x63/0x90 [ 37.295095] ? _raw_spin_lock_irqsave+0x12/0x40 [ 37.295125] ? rcu_torture_stats_print+0x610/0x610 [ 37.295143] rcu_torture_stats+0x29/0x70 [ 37.295160] kthread+0xe3/0x110 [ 37.295176] ? kthread_complete_and_exit+0x20/0x20 [ 37.295193] ret_from_fork+0x22/0x30 [ 37.295218] Fix this with boosting the ksoftirqds kthreads from the boostinghotplug callback itself and before the boosting kthreads are created.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Align upwards buffer sizeThe hardware can support any image size WxH,with arbitrary W (image width) and H (image height) dimensions.Align upwards buffer size for both encoder and decoder.and leave the picture resolution unchanged.For decoder, the risk of memory out of bounds can be avoided.For both encoder and decoder, the driver will lift the limitation ofresolution alignment.For example, the decoder can support jpeg whose resolution is 227x149the encoder can support nv12 1080P, won't change it to 1920x1072.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: encoder_hdmi: Fix refcount leak in meson_encoder_hdmi_initof_graph_get_remote_node() returns remote device nodepointer withrefcount incremented, we should use of_node_put() on it when done.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: qcom: replace gcc PXO with pxo_board fixed clockReplace gcc PXO phandle to pxo_board fixed clock declared in the dts.gcc driver doesn't provide PXO_SRC as it's a fixed-clock. This cause akernel panic if any driver actually try to use it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Clear the connection field properlycoresight devices track their connections (output connections) andhold a reference to the fwnode. When a device goes away, we walk throughthe devices on the coresight bus and make sure that the referencesare dropped. This happens both ways: a) For all output connections from the device, drop the reference to the target device via coresight_release_platform_data()b) Iterate over all the devices on the coresight bus and drop the reference to fwnode if *this* device is the target of the output connection, via coresight_remove_conns()->coresight_remove_match().However, the coresight_remove_match() doesn't clear the fwnode field,after dropping the reference, this causes use-after-free andadditional refcount drops on the fwnode.e.g., if we have two devices, A and B, with a connection, A -> B.If we remove B first, B would clear the reference on B, from Avia coresight_remove_match(). But when A is removed, it still hasa connection with fwnode still pointing to B. Thus it tries to dropsthe reference in coresight_release_platform_data(), raising the bellslike :[ 91.990153] ------------[ cut here ]------------[ 91.990163] refcount_t: addition on 0; use-after-free.[ 91.990212] WARNING: CPU: 0 PID: 461 at lib/refcount.c:25 refcount_warn_saturate+0xa0/0x144[ 91.990260] Modules linked in: coresight_funnel coresight_replicator coresight_etm4x(-) crct10dif_ce coresight ip_tables x_tables ipv6 [last unloaded: coresight_cpu_debug][ 91.990398] CPU: 0 PID: 461 Comm: rmmod Tainted: G W T 5.19.0-rc2+ #53[ 91.990418] Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Feb 1 2019[ 91.990434] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 91.990454] pc : refcount_warn_saturate+0xa0/0x144[ 91.990476] lr : refcount_warn_saturate+0xa0/0x144[ 91.990496] sp : ffff80000c843640[ 91.990509] x29: ffff80000c843640 x28: ffff800009957c28 x27: ffff80000c8439a8[ 91.990560] x26: ffff00097eff1990 x25: ffff8000092b6ad8 x24: ffff00097eff19a8[ 91.990610] x23: ffff80000c8439a8 x22: 0000000000000000 x21: ffff80000c8439c2[ 91.990659] x20: 0000000000000000 x19: ffff00097eff1a10 x18: ffff80000ab99c40[ 91.990708] x17: 0000000000000000 x16: 0000000000000000 x15: ffff80000abf6fa0[ 91.990756] x14: 000000000000001d x13: 0a2e656572662d72 x12: 657466612d657375[ 91.990805] x11: 203b30206e6f206e x10: 6f69746964646120 x9 : ffff8000081aba28[ 91.990854] x8 : 206e6f206e6f6974 x7 : 69646461203a745f x6 : 746e756f63666572[ 91.990903] x5 : ffff00097648ec58 x4 : 0000000000000000 x3 : 0000000000000027[ 91.990952] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00080260ba00[ 91.991000] Call trace:[ 91.991012] refcount_warn_saturate+0xa0/0x144[ 91.991034] kobject_get+0xac/0xb0[ 91.991055] of_node_get+0x2c/0x40[ 91.991076] of_fwnode_get+0x40/0x60[ 91.991094] fwnode_handle_get+0x3c/0x60[ 91.991116] fwnode_get_nth_parent+0xf4/0x110[ 91.991137] fwnode_full_name_string+0x48/0xc0[ 91.991158] device_node_string+0x41c/0x530[ 91.991178] pointer+0x320/0x3ec[ 91.991198] vsnprintf+0x23c/0x750[ 91.991217] vprintk_store+0x104/0x4b0[ 91.991238] vprintk_emit+0x8c/0x360[ 91.991257] vprintk_default+0x44/0x50[ 91.991276] vprintk+0xcc/0xf0[ 91.991295] _printk+0x68/0x90[ 91.991315] of_node_release+0x13c/0x14c[ 91.991334] kobject_put+0x98/0x114[ 91.991354] of_node_put+0x24/0x34[ 91.991372] of_fwnode_put+0x40/0x5c[ 91.991390] fwnode_handle_put+0x38/0x50[ 91.991411] coresight_release_platform_data+0x74/0xb0 [coresight][ 91.991472] coresight_unregister+0x64/0xcc [coresight][ 91.991525] etm4_remove_dev+0x64/0x78 [coresight_etm4x][ 91.991563] etm4_remove_amba+0x1c/0x2c [coresight_etm4x][ 91.991598] amba_remove+0x3c/0x19c---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix KASAN use-after-free Read in compute_effective_progsSyzbot found a Use After Free bug in compute_effective_progs().The reproducer creates a number of BPF links, and causes a faultinjected alloc to fail, while calling bpf_link_detach on them.Link detach triggers the link to be freed by bpf_link_free(),which calls __cgroup_bpf_detach() and update_effective_progs().If the memory allocation in this function fails, the function restoresthe pointer to the bpf_cgroup_link on the cgroup list, but the memorygets freed just after it returns. After this, every subsequent call toupdate_effective_progs() causes this already deallocated pointer to bedereferenced in prog_list_length(), and triggers KASAN UAF error.To fix this issue don't preserve the pointer to the prog or link in thelist, but remove it and replace it with a dummy prog without shrinkingthe table. The subsequent call to __cgroup_bpf_detach() or__cgroup_bpf_detach() will correct it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Treat NX as a valid SPTE bit for NPTTreat the NX bit as valid when using NPT, as KVM will set the NX bit whenthe NX huge page mitigation is enabled (mindblowing) and trigger the WARNthat fires on reserved SPTE bits being set.KVM has required NX support for SVM since commit b26a71a1a5b9 ("KVM: SVM:Refuse to load kvm_amd if NX support is not available") for exactly thisreason, but apparently it never occurred to anyone to actually test NPTwith the mitigation enabled. ------------[ cut here ]------------ spte = 0x800000018a600ee7, level = 2, rsvd bits = 0x800f0000001fe000 WARNING: CPU: 152 PID: 15966 at arch/x86/kvm/mmu/spte.c:215 make_spte+0x327/0x340 [kvm] Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 10.48.0 01/27/2022 RIP: 0010:make_spte+0x327/0x340 [kvm] Call Trace: tdp_mmu_map_handle_target_level+0xc3/0x230 [kvm] kvm_tdp_mmu_map+0x343/0x3b0 [kvm] direct_page_fault+0x1ae/0x2a0 [kvm] kvm_tdp_page_fault+0x7d/0x90 [kvm] kvm_mmu_page_fault+0xfb/0x2e0 [kvm] npf_interception+0x55/0x90 [kvm_amd] svm_invoke_exit_handler+0x31/0xf0 [kvm_amd] svm_handle_exit+0xf6/0x1d0 [kvm_amd] vcpu_enter_guest+0xb6d/0xee0 [kvm] ? kvm_pmu_trigger_event+0x6d/0x230 [kvm] vcpu_run+0x65/0x2c0 [kvm] kvm_arch_vcpu_ioctl_run+0x355/0x610 [kvm] kvm_vcpu_ioctl+0x551/0x610 [kvm] __se_sys_ioctl+0x77/0xc0 __x64_sys_ioctl+0x1d/0x20 do_syscall_64+0x44/0xa0 entry_SYSCALL_64_after_hwframe+0x46/0xb0 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv:uprobe fix SR_SPIE set/clear handlingIn riscv the process of uprobe going to clear spie before execthe origin insn,and set spie after that.But When access the pagewhich origin insn has been placed a page fault may happen andirq was disabled in arch_uprobe_pre_xol function,It cause a WARNas follows.There is no need to clear/set spie in arch_uprobe_pre/post/abort_xol.We can just remove it.[ 31.684157] BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1488[ 31.684677] in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 76, name: work[ 31.684929] preempt_count: 0, expected: 0[ 31.685969] CPU: 2 PID: 76 Comm: work Tainted: G[ 31.686542] Hardware name: riscv-virtio,qemu (DT)[ 31.686797] Call Trace:[ 31.687053] [] dump_backtrace+0x30/0x38[ 31.687699] [] show_stack+0x40/0x4c[ 31.688141] [] dump_stack_lvl+0x44/0x5c[ 31.688396] [] dump_stack+0x18/0x20[ 31.688653] [] __might_resched+0x114/0x122[ 31.688948] [] __might_sleep+0x50/0x7a[ 31.689435] [] down_read+0x30/0x130[ 31.689728] [] do_page_fault+0x166/x446[ 31.689997] [] ret_from_exception+0x0/0xc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50236 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/mediatek: Fix crash on isr after kexec()If the system is rebooted via isr(), the IRQ handler mightbe triggered before the domain is initialized. Resulting onan invalid memory access error.Fix:[ 0.500930] Unable to handle kernel read from unreadable memory at virtual address 0000000000000070[ 0.501166] Call trace:[ 0.501174] report_iommu_fault+0x28/0xfc[ 0.501180] mtk_iommu_isr+0x10c/0x1c0[ joro: Fixed spelling in commit message ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50242 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()If vp alloc failed in qlcnic_sriov_init(), all previously allocated vpneeds to be freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50243 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: handle the error returned from sctp_auth_asoc_init_active_keyWhen it returns an error from sctp_auth_asoc_init_active_key(), theactive_key is actually not updated. The old sh_key will be freeedwhile it's still used as active key in asoc. Then an use-after-freewill be triggered when sending patckets, as found by syzbot: sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112 sctp_set_owner_w net/sctp/socket.c:132 [inline] sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863 sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025 inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:734This patch is to fix it by not replacing the sh_key when it returnserrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().For sctp_auth_set_active_key(), old active_key_id will be set backto asoc->active_key_id when the same thing happens.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_pci_init_afu|adapter()If device_register() fails in cxl_pci_afu|adapter(), the deviceis not added, device_unregister() can not be called in the errorpath, otherwise it will cause a null-ptr-deref because of removingnot added device.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50253 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: make sure skb->len != 0 when redirecting to a tunneling devicesyzkaller managed to trigger another case where skb->len == 0when we enter __dev_queue_xmit:WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295Call Trace: dev_queue_xmit+0x17/0x20 net/core/dev.c:4406 __bpf_tx_skb net/core/filter.c:2115 [inline] __bpf_redirect_no_mac net/core/filter.c:2140 [inline] __bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163 ____bpf_clone_redirect net/core/filter.c:2447 [inline] bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419 bpf_prog_48159a89cb4a9a16+0x59/0x5e bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline] __bpf_prog_run include/linux/filter.h:596 [inline] bpf_prog_run include/linux/filter.h:603 [inline] bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402 bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170 bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648 __sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005 __do_sys_bpf kernel/bpf/syscall.c:5091 [inline] __se_sys_bpf kernel/bpf/syscall.c:5089 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089 do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48 entry_SYSCALL_64_after_hwframe+0x61/0xc6The reproducer doesn't really reproduce outside of syzkallerenvironment, so I'm taking a guess here. It looks like wedo generate correct ETH_HLEN-sized packet, but we redirectthe packet to the tunneling device. Before we do so, we__skb_pull l2 header and arrive again at skb->len == 0.Doesn't seem like we can do anything better than havingan explicit check after __skb_pull?

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: fix race in sock_map_free()sock_map_free() calls release_sock(sk) without owning a referenceon the socket. This can cause use-after-free as syzbot found [1]Jakub Sitnicki already took care of a similar issuein sock_hash_free() in commit 75e68e5bf2c7 ("bpf, sockhash:Synchronize delete from bucket list on map free")[1]refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Modules linked in:CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: events_unbound bpf_map_free_deferredRIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ffRSP: 0018:ffffc9000456fb60 EFLAGS: 00010246RAX: eae59bab72dcd700 RBX: 0000000000000004 RCX: ffff8880207057c0RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: 0000000000000004 R08: ffffffff816fdabd R09: fffff520008adee5R10: fffff520008adee5 R11: 1ffff920008adee4 R12: 0000000000000004R13: dffffc0000000000 R14: ffff88807b1c6c00 R15: 1ffff1100f638dcfFS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30c30000 CR3: 000000000d08e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__refcount_dec include/linux/refcount.h:344 [inline]refcount_dec include/linux/refcount.h:359 [inline]__sock_put include/net/sock.h:779 [inline]tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092release_sock+0xaf/0x1c0 net/core/sock.c:3468sock_map_free+0x219/0x2c0 net/core/sock_map.c:356process_one_work+0x81c/0xd10 kernel/workqueue.c:2289worker_thread+0xb14/0x1330 kernel/workqueue.c:2436kthread+0x266/0x300 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50265 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_waitkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.syzbot reported:BUG: KCSAN: data-race in kcm_rcv_strparser / kcm_rfreewrite to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1:reserve_rx_kcm net/kcm/kcmsock.c:283 [inline]kcm_rcv_strparser+0x250/0x3a0 net/kcm/kcmsock.c:363__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0:kcm_rfree+0x121/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x01 -> 0x00Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on destination blkaddr during recoveryAs Wenqing Liu reported in bugzilla:https://bugzilla.kernel.org/show_bug.cgi?id=216456loop5: detected capacity change from 0 to 131072F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0F2FS-fs (loop5): Bitmap was wrongly set, blk:5634------------[ cut here ]------------WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]Call Trace: f2fs_do_replace_block+0xa98/0x1890 [f2fs] f2fs_replace_block+0xeb/0x180 [f2fs] recover_data+0x1a69/0x6ae0 [f2fs] f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs] f2fs_fill_super+0x4665/0x61e0 [f2fs] mount_bdev+0x2cf/0x3b0 legacy_get_tree+0xed/0x1d0 vfs_get_tree+0x81/0x2b0 path_mount+0x47e/0x19d0 do_mount+0xce/0xf0 __x64_sys_mount+0x12c/0x1a0 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdIf we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panicinstead of warning.The root cause is: in fuzzed image, SIT table is inconsistent with inodemapping table, result in triggering such warning during SIT table update.This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ thisflag, data block recovery flow can check destination blkaddr's validationin SIT table, and skip f2fs_replace_block() to avoid inconsistent status.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pnode: terminate at peers of sourceThe propagate_mnt() function handles mount propagation when creatingmounts and propagates the source mount tree @source_mnt to allapplicable nodes of the destination propagation mount tree headed by@dest_mnt.Unfortunately it contains a bug where it fails to terminate at peers of@source_mnt when looking up copies of the source mount that becomemasters for copies of the source mount tree mounted on top of slaves inthe destination propagation tree causing a NULL dereference.Once the mechanics of the bug are understood it's easy to trigger.Because of unprivileged user namespaces it is available to unprivilegedusers.While fixing this bug we've gotten confused multiple times due tounclear terminology or missing concepts. So let's start this with someclarifications:* The terms "master" or "peer" denote a shared mount. A shared mount belongs to a peer group.* A peer group is a set of shared mounts that propagate to each other. They are identified by a peer group id. The peer group id is available in @shared_mnt->mnt_group_id. Shared mounts within the same peer group have the same peer group id. The peers in a peer group can be reached via @shared_mnt->mnt_share.* The terms "slave mount" or "dependent mount" denote a mount that receives propagation from a peer in a peer group. IOW, shared mounts may have slave mounts and slave mounts have shared mounts as their master. Slave mounts of a given peer in a peer group are listed on that peers slave list available at @shared_mnt->mnt_slave_list.* The term "master mount" denotes a mount in a peer group. IOW, it denotes a shared mount or a peer mount in a peer group. The term "master mount" - or "master" for short - is mostly used when talking in the context of slave mounts that receive propagation from a master mount. A master mount of a slave identifies the closest peer group a slave mount receives propagation from. The master mount of a slave can be identified via @slave_mount->mnt_master. Different slaves may point to different masters in the same peer group.* Multiple peers in a peer group can have non-empty ->mnt_slave_lists. Non-empty ->mnt_slave_lists of peers don't intersect. Consequently, to ensure all slave mounts of a peer group are visited the ->mnt_slave_lists of all peers in a peer group have to be walked.* Slave mounts point to a peer in the closest peer group they receive propagation from via @slave_mnt->mnt_master (see above). Together with these peers they form a propagation group (see below). The closest peer group can thus be identified through the peer group id @slave_mnt->mnt_master->mnt_group_id of the peer/master that a slave mount receives propagation from.* A shared-slave mount is a slave mount to a peer group pg1 while also a peer in another peer group pg2. IOW, a peer group may receive propagation from another peer group. If a peer group pg1 is a slave to another peer group pg2 then all peers in peer group pg1 point to the same peer in peer group pg2 via ->mnt_master. IOW, all peers in peer group pg1 appear on the same ->mnt_slave_list. IOW, they cannot be slaves to different peer groups.* A pure slave mount is a slave mount that is a slave to a peer group but is not a peer in another peer group.* A propagation group denotes the set of mounts consisting of a single peer group pg1 and all slave mounts and shared-slave mounts that point to a peer in that peer group via ->mnt_master. IOW, all slave mounts such that @slave_mnt->mnt_master->mnt_group_id is equal to @shared_mnt->mnt_group_id. The concept of a propagation group makes it easier to talk about a single propagation level in a propagation tree. For example, in propagate_mnt() the immediate peers of @dest_mnt and all slaves of @dest_mnt's peer group form a propagation group pr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()In error case in bridge_platform_create after callingplatform_device_add()/platform_device_add_data()/platform_device_add_resources(), release the failed'pdev' or it will be leak, call platform_device_put()to fix this problem.Besides, 'pdev' is divided into 'pdev_wd' and 'pdev_bd',use platform_device_unregister() to release sgi_w1resources when xtalk-bridge registration fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm,hugetlb: take hugetlb_lock before decrementing h->resv_huge_pagesThe h->*_huge_pages counters are protected by the hugetlb_lock, butalloc_huge_page has a corner case where it can decrement the counteroutside of the lock.This could lead to a corrupted value of h->resv_huge_pages, which we haveobserved on our systems.Take the hugetlb_lock before decrementing h->resv_huge_pages to avoid apotential race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: annotate data-races around kcm->rx_psockkcm->rx_psock can be read locklessly in kcm_rfree().Annotate the read and writes accordingly.We do the same for kcm->rx_wait in the following patch.syzbot reported:BUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcmwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:unreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313kcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301strp_recv+0x6d/0x80 net/strparser/strparser.c:335tcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703strp_read_sock net/strparser/strparser.c:358 [inline]do_strp_work net/strparser/strparser.c:406 [inline]strp_work+0xe8/0x180 net/strparser/strparser.c:415process_one_work+0x3d3/0x720 kernel/workqueue.c:2289worker_thread+0x618/0xa70 kernel/workqueue.c:2436kthread+0x1a9/0x1e0 kernel/kthread.c:376ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:kcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181skb_release_head_state+0x8e/0x160 net/core/skbuff.c:841skb_release_all net/core/skbuff.c:852 [inline]__kfree_skb net/core/skbuff.c:868 [inline]kfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891kfree_skb include/linux/skbuff.h:1216 [inline]kcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161____sys_recvmsg+0x16c/0x2e0___sys_recvmsg net/socket.c:2743 [inline]do_recvmmsg+0x2f1/0x710 net/socket.c:2837__sys_recvmmsg net/socket.c:2916 [inline]__do_sys_recvmmsg net/socket.c:2939 [inline]__se_sys_recvmmsg net/socket.c:2932 [inline]__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff88812971ce00 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50293 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() on ENOMEM when dropping extent items for a rangeIf we get -ENOMEM while dropping file extent items in a given range, atbtrfs_drop_extents(), due to failure to allocate memory when attempting toincrement the reference count for an extent or drop the reference count,we handle it with a BUG_ON(). This is excessive, instead we can simplyabort the transaction and return the error to the caller. In fact mostcallers of btrfs_drop_extents(), directly or indirectly, already abortthe transaction if btrfs_drop_extents() returns any error.Also, we already have error paths at btrfs_drop_extents() that may return-ENOMEM and in those cases we abort the transaction, like for exampleanything that changes the b+tree may return -ENOMEM due to a failure toallocate a new extent buffer when COWing an existing extent buffer, suchas a call to btrfs_duplicate_item() for example.So replace the BUG_ON() calls with proper logic to abort the transactionand return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50300 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix extent map use-after-free when handling missing device in read_one_chunkStore the error code before freeing the extent_map. Though it'sreference counted structure, in that function it's the first and lastallocation so this would lead to a potential use-after-free.The error can happen eg. when chunk is stored on a missing device andthe degraded mount option is missing.Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216721

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50303 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix double release compute pasidIf kfd_process_device_init_vm returns failure after vm is converted tocompute vm and vm->pasid set to compute pasid, KFD will not takepdd->drm_file reference. As a result, drm close file handler maybecalled to release the compute pasid before KFD process destroy worker torelease the same pasid and set vm->pasid to zero, this generates belowWARNING backtrace and NULL pointer access.Add helper amdgpu_amdkfd_gpuvm_set_vm_pasid and call it at the last stepof kfd_process_device_init_vm, to ensure vm pasid is the original pasidif acquiring vm failed or is the compute pasid with pdd->drm_filereference taken to avoid double release same pasid. amdgpu: Failed to create process VM object ida_free called for id=32770 which is not allocated. WARNING: CPU: 57 PID: 72542 at ../lib/idr.c:522 ida_free+0x96/0x140 RIP: 0010:ida_free+0x96/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10 BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:ida_free+0x76/0x140 Call Trace: amdgpu_pasid_free_delayed+0xe1/0x2a0 [amdgpu] amdgpu_driver_postclose_kms+0x2d8/0x340 [amdgpu] drm_file_free.part.13+0x216/0x270 [drm] drm_close_helper.isra.14+0x60/0x70 [drm] drm_release+0x6e/0xf0 [drm] __fput+0xcc/0x280 ____fput+0xe/0x20 task_work_run+0x96/0xc0 do_exit+0x3d0/0xc10

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: core: fix possible resource leak in init_mtd()I got the error report while inject fault in init_mtd():sysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'Call Trace: dump_stack_lvl+0x67/0x83 sysfs_warn_dup+0x60/0x70 sysfs_create_dir_ns+0x109/0x120 kobject_add_internal+0xce/0x2f0 kobject_add+0x98/0x110 device_add+0x179/0xc00 device_create_groups_vargs+0xf4/0x100 device_create+0x7b/0xb0 bdi_register_va.part.13+0x58/0x2d0 bdi_register+0x9b/0xb0 init_mtd+0x62/0x171 [mtd] do_one_initcall+0x6c/0x3c0 do_init_module+0x58/0x222 load_module+0x268e/0x27d0 __do_sys_finit_module+0xd5/0x140 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd kobject_add_internal failed for mtd-0 with -EEXIST, don't try to register things with the same name in the same directory.Error registering mtd class or bdi: -17If init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,as a result, we can't load the mtd module again, to fix this by callingbdi_unregister(mtd_bdi) after out_procfs label.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50311 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix refcount leak in cxl_calc_capp_routingof_get_next_parent() returns a node pointer with refcount incremented,we should use of_node_put() on it when not need anymore.This function only calls of_node_put() in normal path,missing it in the error path.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix order >= MAX_ORDER warning due to crafted negative i_sizeAs syzbot reported [1], the root cause is that i_size field is asigned type, and negative i_size is also less than EROFS_BLKSIZ.As a consequence, it's handled as fast symlink unexpectedly.Let's fall back to the generic path to deal with such unusual i_size.[1] https://lore.kernel.org/r/000000000000ac8efa05e7feaa1f@google.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50316 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: Fix kmemleak in orangefs_sysfs_init()When insert and remove the orangefs module, there are kobjects memoryleaked as below:unreferenced object 0xffff88810f95af00 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff ................ 08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae80 (size 64): comm "insmod", pid 783, jiffies 4294813439 (age 65.512s) hex dump (first 32 bytes): c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff ................ 88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ae00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff `............... 08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ad80 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.511s) hex dump (first 32 bytes): 78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff x............... 88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/0x80 [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0unreferenced object 0xffff88810f95ac00 (size 64): comm "insmod", pid 783, jiffies 4294813440 (age 65.531s) hex dump (first 32 bytes): e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff ..g............. 08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000031ab7788>] kmalloc_trace+0x27/0xa0 [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0 [<00000000722645ca>] 0xffffffffa02780fe [<000000004232d9f7>] do_one_initcall+0x87/0x2a0 [<0000000054f22384>] do_init_module+0xdf/0x320 [<000000003263bdea>] load_module+0x2f98/0x3330 [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0 [<00000000250ae02b>] do_syscall_64+0x35/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: remove cpuhp instance node before remove cpuhp statecpuhp_state_add_instance() and cpuhp_state_remove_instance() shouldbe used in pairs. Or there will lead to the warn oncpuhp_remove_multi_state() since the cpuhp_step list is not empty.The following is the error log with 'rmmod coresight-trbe':Error: Removing state 215 which has instances left.Call trace: __cpuhp_remove_state_cpuslocked+0x144/0x160 __cpuhp_remove_state+0xac/0x100 arm_trbe_device_remove+0x2c/0x60 [coresight_trbe] platform_remove+0x34/0x70 device_remove+0x54/0x90 device_release_driver_internal+0x1e4/0x250 driver_detach+0x5c/0xb0 bus_remove_driver+0x64/0xc0 driver_unregister+0x3c/0x70 platform_driver_unregister+0x20/0x30 arm_trbe_exit+0x1c/0x658 [coresight_trbe] __arm64_sys_delete_module+0x1ac/0x24c invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x58/0x1a0 do_el0_svc+0x38/0xd0 el0_svc+0x2c/0xc0 el0t_64_sync_handler+0x1ac/0x1b0 el0t_64_sync+0x19c/0x1a0 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50335 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p: set req refcount to zero to avoid uninitialized usageWhen a new request is allocated, the refcount will be zero if it isreused, but if the request is newly allocated from slab, it is not fullyinitialized before being added to idr.If the p9_read_work got a response before the refcount initiated. It willuse a uninitialized req, which will result in a bad request data struct.Here is the logs from syzbot.Corrupted memory at 0xffff88807eade00b [ 0xff 0x07 0x00 0x00 0x00 0x000x00 0x00 . . . . . . . . ] (in kfence-#110): p9_fcall_fini net/9p/client.c:248 [inline] p9_req_put net/9p/client.c:396 [inline] p9_req_put+0x208/0x250 net/9p/client.c:390 p9_client_walk+0x247/0x540 net/9p/client.c:1165 clone_fid fs/9p/fid.h:21 [inline] v9fs_fid_xattr_set+0xe4/0x2b0 fs/9p/xattr.c:118 v9fs_xattr_set fs/9p/xattr.c:100 [inline] v9fs_xattr_handler_set+0x6f/0x120 fs/9p/xattr.c:159 __vfs_setxattr+0x119/0x180 fs/xattr.c:182 __vfs_setxattr_noperm+0x129/0x5f0 fs/xattr.c:216 __vfs_setxattr_locked+0x1d3/0x260 fs/xattr.c:277 vfs_setxattr+0x143/0x340 fs/xattr.c:309 setxattr+0x146/0x160 fs/xattr.c:617 path_setxattr+0x197/0x1c0 fs/xattr.c:636 __do_sys_setxattr fs/xattr.c:652 [inline] __se_sys_setxattr fs/xattr.c:648 [inline] __ia32_sys_setxattr+0xc0/0x160 fs/xattr.c:648 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82Below is a similar scenario, the scenario in the syzbot log looks morecomplicated than this one, but this patch can fix it. T21124 p9_read_work======================== second trans =================================p9_client_walk p9_client_rpc p9_client_prepare_req p9_tag_alloc req = kmem_cache_alloc(p9_req_cache, GFP_NOFS); tag = idr_alloc << preempted >> req->tc.tag = tag; /* req->[refcount/tag] == uninitialized */ m->rreq = p9_tag_lookup(m->client, m->rc.tag); /* increments uninitalized refcount */ refcount_set(&req->refcount, 2); /* cb drops one ref */ p9_client_cb(req) /* reader thread drops its ref: request is incorrectly freed */ p9_req_put(req) /* use after free and ref underflow */ p9_req_put(req)To fix it, we can initialize the refcount to zero before add to idr.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocxl: fix pci device refcount leak when calling get_function_0()get_function_0() calls pci_get_domain_bus_and_slot(), as commentsays, it returns a pci device with refcount increment, so afterusing it, pci_dev_put() needs be called.Get the device reference when get_function_0() is not called, sopci_dev_put() can be called in the error path and callersunconditionally. And add comment above get_dvsec_vendor0() to tellcallers to call pci_dev_put().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50338 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50352 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns: fix possible memory leak in hnae_ae_register()Inject fault while probing module, if device_register() fails,but the refcount of kobject is not decreased to 0, the nameallocated in dev_set_name() is leaked. Fix this by callingput_device(), so that name can be freed in callback functionkobject_cleanup().unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0 [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0 [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8 [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0 [<000000000b87affc>] dev_set_name+0x7c/0xa0 [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae] [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf] [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix kfd_process_device_init_vm error handlingShould only destroy the ib_mem and let process cleanup worker to freethe outstanding BOs. Reset the pointer in pdd->qpd structure, to avoidNULL pointer access in process destroy worker. BUG: kernel NULL pointer dereference, address: 0000000000000010 Call Trace: amdgpu_amdkfd_gpuvm_unmap_gtt_bo_from_kernel+0x46/0xb0 [amdgpu] kfd_process_device_destroy_cwsr_dgpu+0x40/0x70 [amdgpu] kfd_process_destroy_pdds+0x71/0x190 [amdgpu] kfd_process_wq_release+0x2a2/0x3b0 [amdgpu] process_one_work+0x2a1/0x600 worker_thread+0x39/0x3d0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50356 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: sfb: fix null pointer access issue when sfb_init() failsWhen the default qdisc is sfb, if the qdisc of dev_queue fails to beinited during mqprio_init(), sfb_reset() is invoked to clear resources.In this case, the q->qdisc is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() sfb_init() tcf_block_get() --->failed, q->qdisc is NULL ... qdisc_put() ... sfb_reset() qdisc_reset(q->qdisc) --->q->qdisc is NULL ops = qdisc->opsThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]RIP: 0010:qdisc_reset+0x2b/0x6f0Call Trace:sfb_reset+0x37/0xd0qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f2164122d04

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50357 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: core: fix some leaks in probeThe dwc3_get_properties() function calls: dwc->usb_psy = power_supply_get_by_name(usb_psy_name);so there is some additional clean up required on these error paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50365 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: Account for tail adjustment during pull operationsExtending the tail can have some unexpected side effects if a program usesa helper like BPF_FUNC_skb_pull_data to read partial content beyond thehead skb headlen when all the skbs in the gso frag_list are linear with nohead_frag - kernel BUG at net/core/skbuff.c:4219! pc : skb_segment+0xcf4/0xd2c lr : skb_segment+0x63c/0xd2c Call trace: skb_segment+0xcf4/0xd2c __udp_gso_segment+0xa4/0x544 udp4_ufo_fragment+0x184/0x1c0 inet_gso_segment+0x16c/0x3a4 skb_mac_gso_segment+0xd4/0x1b0 __skb_gso_segment+0xcc/0x12c udp_rcv_segment+0x54/0x16c udp_queue_rcv_skb+0x78/0x144 udp_unicast_rcv_skb+0x8c/0xa4 __udp4_lib_rcv+0x490/0x68c udp_rcv+0x20/0x30 ip_protocol_deliver_rcu+0x1b0/0x33c ip_local_deliver+0xd8/0x1f0 ip_rcv+0x98/0x1a4 deliver_ptype_list_skb+0x98/0x1ec __netif_receive_skb_core+0x978/0xc60Fix this by marking these skbs as GSO_DODGY so segmentation can handlethe tail updates accordingly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50382 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: Always leave BHs disabled when running ->parallel()A deadlock can happen when an overloaded system runs ->parallel() in thecontext of the current task: padata_do_parallel ->parallel() pcrypt_aead_enc/dec padata_do_serial spin_lock(&reorder->lock) // BHs still enabled ... __do_softirq ... padata_do_serial spin_lock(&reorder->lock)It's a bug for BHs to be on in _do_serial as Steffen points out, soensure they're off in the "current task" case like they are inpadata_parallel_worker to avoid this situation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50384 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: vme_user: Fix possible UAF in tsi148_dma_list_addSmatch report warning as follows:drivers/staging/vme_user/vme_tsi148.c:1757 tsi148_dma_list_add() warn: '&entry->list' not removed from listIn tsi148_dma_list_add(), the error path "goto err_dma" will notremove entry->list from list->entries, but entry will be freed,then list traversal may cause UAF.Fix by removeing it from list->entries before free().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50387 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: fix the issue of CMDQ memory leaksWhen hinic_set_cmdq_depth() fails in hinic_init_cmdqs(), the cmdq memory isnot released correctly. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50390 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATEDShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26left shift of 1 by 31 places cannot be represented in type 'int'Call Trace: dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c ttm_bo_move_memcpy+0x3b4/0x460 [ttm] bo_driver_move+0x32/0x40 [drm_vram_helper] ttm_bo_handle_move_mem+0x118/0x200 [ttm] ttm_bo_validate+0xfa/0x220 [ttm] drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper] drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper] drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper] drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper] drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper] drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper] drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper] drm_atomic_commit+0x9c/0x160 [drm] drm_client_modeset_commit_atomic+0x33a/0x380 [drm] drm_client_modeset_commit_locked+0x77/0x220 [drm] drm_client_modeset_commit+0x31/0x60 [drm] __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper] drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper] fbcon_init+0x316/0x790 visual_init+0x113/0x1d0 do_bind_con_driver+0x2a3/0x5c0 do_take_over_console+0xa9/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50396 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: fix memory leak in tcindex_set_parmsSyzkaller reports a memory leak as follows:====================================BUG: memory leakunreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] kmalloc_array include/linux/slab.h:627 [inline] [] kcalloc include/linux/slab.h:659 [inline] [] tcf_exts_init include/net/pkt_cls.h:250 [inline] [] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [] sock_sendmsg_nosec net/socket.c:714 [inline] [] sock_sendmsg+0x56/0x80 net/socket.c:734 [] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [] __do_sys_sendmmsg net/socket.c:2651 [inline] [] __se_sys_sendmmsg net/socket.c:2648 [inline] [] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd====================================Kernel uses tcindex_change() to change an existingfilter properties.Yet the problem is that, during the process of changing,if `old_r` is retrieved from `p->perfect`, thenkernel uses tcindex_alloc_perfect_hash() to newlyallocate filter results, uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure, which triggers the above memory leak.To be more specific, there are only two source for the `old_r`,according to the tcindex_lookup(). `old_r` is retrieved from`p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel usestcindex_alloc_perfect_hash() to newly allocate thefilter results. Then `r` is assigned with `cp->perfect + handle`,which is newly allocated. So condition `old_r && old_r != r` istrue in this situation, and kernel uses tcindex_filter_result_init()to clear the old filter result, without destroyingits tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULLaccording to the tcindex_lookup(). Considering that `cp->h`is directly copied from `p->h` and `p->perfect` is NULL,`r` is assigned with `tcindex_lookup(cp, handle)`, whose valueshould be the same as `old_r`, so condition `old_r && old_r != r`is false in this situation, kernel ignores usingtcindex_filter_result_init() to clear the old filter result.So only when `old_r` is retrieved from `p->perfect` does kernel usetcindex_filter_result_init() to clear the old filter result, whichtriggers the above memory leak.Considering that there already exists a tc_filter_wq workqueueto destroy the old tcindex_d---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50406 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iomap: iomap: fix memory corruption when recording errors during writebackEvery now and then I see this crash on arm64:Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8Buffer I/O error on dev dm-0, logical block 8733687, async page readMem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation faultData abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000[00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000Internal error: Oops: 96000006 [#1] PREEMPT SMPBuffer I/O error on dev dm-0, logical block 8733688, async page readDumping ftrace buffer:Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty)XFS (dm-0): log I/O error -5Modules linked in: dm_thin_pool dm_persistent_dataXFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ec/0x590 [xfs] (fs/xfs/xfs_trans_buf.c:296). dm_bio_prisonXFS (dm-0): Please unmount the filesystem and rectify the problem(s)XFS (dm-0): xfs_imap_lookup: xfs_ialloc_read_agi() returned error -5, agno 0 dm_bufio dm_log_writes xfs nft_chain_nat xt_REDIRECT nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_REJECTpotentially unexpected fatal signal 6. nf_reject_ipv6potentially unexpected fatal signal 6. ipt_REJECT nf_reject_ipv4CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsec_gss_krb5 auth_rpcgss xt_tcpudp ip_set_hash_ip ip_set_hash_net xt_set nft_compat ip_set_hash_mac ip_set nf_tablesHardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) ip_tablespc : 000003fd6d7df200 x_tableslr : 000003fd6d7df1ec overlay nfsv4CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021Workqueue: writeback wb_workfnsp : 000003ffd9522fd0 (flush-253:0)pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--)pc : errseq_set+0x1c/0x100x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000x23: 00000000ffffffff x22: 0000000000000005lr : __filemap_set_wb_err+0x24/0xe0 x21: 0000000000000006sp : fffffe000f80f760x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8Call trace: errseq_set+0x1c/0x100 __filemap_set_wb_err+0x24/0xe0 iomap_do_writepage+0x5e4/0xd5c write_cache_pages+0x208/0x674 iomap_writepages+0x34/0x60 xfs_vm_writepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b]x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffeex5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000CPU: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50412 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: adv7511: unregister cec i2c device after cec adaptercec_unregister_adapter() assumes that the underlying adapter ops arecallable. For example, if the CEC adapter currently has a valid physicaladdress, then the unregistration procedure will invalidate the physicaladdress by setting it to f.f.f.f. Whence the following kernel oopsobserved after removing the adv7511 module: Unable to handle kernel execution of user memory at virtual address 0000000000000000 Internal error: Oops: 86000004 [#1] PREEMPT_RT SMP Call trace: 0x0 adv7511_cec_adap_log_addr+0x1ac/0x1c8 [adv7511] cec_adap_unconfigure+0x44/0x90 [cec] __cec_s_phys_addr.part.0+0x68/0x230 [cec] __cec_s_phys_addr+0x40/0x50 [cec] cec_unregister_adapter+0xb4/0x118 [cec] adv7511_remove+0x60/0x90 [adv7511] i2c_device_remove+0x34/0xe0 device_release_driver_internal+0x114/0x1f0 driver_detach+0x54/0xe0 bus_remove_driver+0x60/0xd8 driver_unregister+0x34/0x60 i2c_del_driver+0x2c/0x68 adv7511_exit+0x1c/0x67c [adv7511] __arm64_sys_delete_module+0x154/0x288 invoke_syscall+0x48/0x100 el0_svc_common.constprop.0+0x48/0xe8 do_el0_svc+0x28/0x88 el0_svc+0x1c/0x50 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x15c/0x160 Code: bad PC value ---[ end trace 0000000000000000 ]---Protect against this scenario by unregistering i2c_cec afterunregistering the CEC adapter. Duly disable the CEC clock afterwardstoo.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/wpcm450: Fix memory leak in wpcm450_aic_of_init()If of_iomap() failed, 'aic' should be freed before return. Otherwisethere is a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50418 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: mhi: fix potential memory leak in ath11k_mhi_register()mhi_alloc_controller() allocates a memory space for mhi_ctrl. When getssome error, mhi_ctrl should be freed with mhi_free_controller(). Butwhen ath11k_mhi_read_addr_from_dt() fails, the function returns withoutcalling mhi_free_controller(), which will lead to a memory leak.We can fix it by calling mhi_free_controller() whenath11k_mhi_read_addr_from_dt() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50438 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hinic: fix memory leak when reading function tableWhen the input parameter idx meets the expected case option inhinic_dbg_get_func_table(), read_data is not released. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50452 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cake: fix null pointer access issue when cake_init() failsWhen the default qdisc is cake, if the qdisc of dev_queue fails to beinited during mqprio_init(), cake_reset() is invoked to clearresources. In this case, the tins is NULL, and it will cause gpf issue.The process is as follows:qdisc_create_dflt() cake_init() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdisc_put() ... cake_reset() ... cake_dequeue_one() b = &q->tins[...] --->q->tins is NULLThe following is the Call Trace information:general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]RIP: 0010:cake_dequeue_one+0xc9/0x3c0Call Trace:cake_reset+0xb1/0x140qdisc_reset+0xed/0x6f0qdisc_destroy+0x82/0x4c0qdisc_put+0x9e/0xb0qdisc_create_dflt+0x2c3/0x4a0mqprio_init+0xa71/0x1760qdisc_create+0x3eb/0x1000tc_modify_qdisc+0x408/0x1720rtnetlink_rcv_msg+0x38e/0xac0netlink_rcv_skb+0x12d/0x3a0netlink_unicast+0x4a2/0x740netlink_sendmsg+0x826/0xcc0sock_sendmsg+0xc5/0x100____sys_sendmsg+0x583/0x690___sys_sendmsg+0xe8/0x160__sys_sendmsg+0xbf/0x160do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7f89e5122d04

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50461 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: Fix PM runtime leakage in am65_cpsw_nuss_ndo_slave_open()Ensure pm_runtime_put() is issued in error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50464 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()As comment of pci_get_device() says, it returns a pci_device with itsrefcount increased. We need to call pci_dev_put() to decrease therefcount. Save the return value of pci_get_device() and callpci_dev_put() to decrease the refcount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50471 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen/gntdev: Accommodate VMA splittingPrior to this commit, the gntdev driver code did not handle thefollowing scenario correctly with paravirtualized (PV) Xen domains:* User process sets up a gntdev mapping composed of two grant mappings (i.e., two pages shared by another Xen domain).* User process munmap()s one of the pages.* User process munmap()s the remaining page.* User process exits.In the scenario above, the user process would cause the kernel to logthe following messages in dmesg for the first munmap(), and the secondmunmap() call would result in similar log messages: BUG: Bad page map in process doublemap.test pte:... pmd:... page:0000000057c97bff refcount:1 mapcount:-1 \ mapping:0000000000000000 index:0x0 pfn:... ... page dumped because: bad pte ... file:gntdev fault:0x0 mmap:gntdev_mmap [xen_gntdev] readpage:0x0 ... Call Trace: dump_stack_lvl+0x46/0x5e print_bad_pte.cold+0x66/0xb6 unmap_page_range+0x7e5/0xdc0 unmap_vmas+0x78/0xf0 unmap_region+0xa8/0x110 __do_munmap+0x1ea/0x4e0 __vm_munmap+0x75/0x120 __x64_sys_munmap+0x28/0x40 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x61/0xcb ...For each munmap() call, the Xen hypervisor (if built with CONFIG_DEBUG)would print out the following and trigger a general protection fault inthe affected Xen PV domain: (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ... (XEN) d0v... Attempt to implicitly unmap d0's grant PTE ...As of this writing, gntdev_grant_map structure's vma field (referred toas map->vma below) is mainly used for checking the start and endaddresses of mappings. However, with split VMAs, these may change, andthere could be more than one VMA associated with a gntdev mapping.Hence, remove the use of map->vma and rely on map->pages_vm_start forthe original start address and on (map->count << PAGE_SHIFT) for theoriginal mapping size. Let the invalidate() and find_special_page()hooks use these.Also, given that there can be multiple VMAs associated with a gntdevmapping, move the "mmu_interval_notifier_remove(&map->notifier)" call tothe end of gntdev_put_map, so that the MMU notifier is only removedafter the closing of the last remaining VMA.Finally, use an atomic to prevent inadvertent gntdev mapping re-use,instead of using the map->live_grants atomic counter and/or the map->vmapointer (the latter of which is now removed). This prevents theuserspace from mmap()'ing (with MAP_FIXED) a gntdev mapping over thesame address range as a previously set up gntdev mapping. This scenariocan be summarized with the following call-trace, which was valid priorto this commit: mmap gntdev_mmap mmap (repeat mmap with MAP_FIXED over the same address range) gntdev_invalidate unmap_grant_pages (sets 'being_removed' entries to true) gnttab_unmap_refs_async unmap_single_vma gntdev_mmap (maps the shared pages again) munmap gntdev_invalidate unmap_grant_pages (no-op because 'being_removed' entries are true) unmap_single_vma (For PV domains, Xen reports that a granted page is being unmapped and triggers a general protection fault in the affected domain, if Xen was built with CONFIG_DEBUG)The fix for this last scenario could be worth its own commit, but weopted for a single commit, because removing the gntdev_grant_mapstructure's vma field requires guarding the entry to gntdev_mmap(), andthe live_grants atomic counter is not sufficient on its own to preventthe mmap() over a pre-existing mapping.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50472 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:IB/mad: Don't call to function that might sleep while in atomic contextTracepoints are not allowed to sleep, as such the following splat isgenerated due to call to ib_query_pkey() in atomic context.WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50473 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: Init completion before kobject_init_and_add()In cpufreq_policy_alloc(), it will call uninitialed completion incpufreq_sysfs_release() when kobject_init_and_add() fails. Andthat will cause a crash such as the following page fault in complete:BUG: unable to handle page fault for address: fffffffffffffff8[..]RIP: 0010:complete+0x98/0x1f0[..]Call Trace: kobject_put+0x1be/0x4c0 cpufreq_online.cold+0xee/0x1fd cpufreq_add_dev+0x183/0x1e0 subsys_interface_register+0x3f5/0x4e0 cpufreq_register_driver+0x3b7/0x670 acpi_cpufreq_init+0x56c/0x1000 [acpi_cpufreq] do_one_initcall+0x13d/0x780 do_init_module+0x1c3/0x630 load_module+0x6e67/0x73b0 __do_sys_finit_module+0x181/0x240 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50475 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Make sure "ib_port" is valid when access sysfs nodeThe "ib_port" structure must be set before adding the sysfs kobject,and reset after removing it, otherwise it may crash when accessingthe sysfs node: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x96000006 Exception class = DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000e85f5ba5 [0000000000000050] pgd=0000000848fd9003, pud=000000085b387003, pmd=0000000000000000 Internal error: Oops: 96000006 [#2] PREEMPT SMP Modules linked in: ib_umad(O) mlx5_ib(O) nfnetlink_cttimeout(E) nfnetlink(E) act_gact(E) cls_flower(E) sch_ingress(E) openvswitch(E) nsh(E) nf_nat_ipv6(E) nf_nat_ipv4(E) nf_conncount(E) nf_nat(E) nf_conntrack(E) nf_defrag_ipv6(E) nf_defrag_ipv4(E) mst_pciconf(O) ipmi_devintf(E) ipmi_msghandler(E) ipmb_dev_int(OE) mlx5_core(O) mlxfw(O) mlxdevm(O) auxiliary(O) ib_uverbs(O) ib_core(O) mlx_compat(O) psample(E) sbsa_gwdt(E) uio_pdrv_genirq(E) uio(E) mlxbf_pmc(OE) mlxbf_gige(OE) mlxbf_tmfifo(OE) gpio_mlxbf2(OE) pwr_mlxbf(OE) mlx_trio(OE) i2c_mlxbf(OE) mlx_bootctl(OE) bluefield_edac(OE) knem(O) ip_tables(E) ipv6(E) crc_ccitt(E) [last unloaded: mst_pci] Process grep (pid: 3372, stack limit = 0x0000000022055c92) CPU: 5 PID: 3372 Comm: grep Tainted: G D OE 4.19.161-mlnx.47.gadcd9e3 #1 Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS BlueField:3.9.2-15-ga2403ab Sep 8 2022 pstate: 40000005 (nZcv daif -PAN -UAO) pc : hw_stat_port_show+0x4c/0x80 [ib_core] lr : port_attr_show+0x40/0x58 [ib_core] sp : ffff000029f43b50 x29: ffff000029f43b50 x28: 0000000019375000 x27: ffff8007b821a540 x26: ffff000029f43e30 x25: 0000000000008000 x24: ffff000000eaa958 x23: 0000000000001000 x22: ffff8007a4ce3000 x21: ffff8007baff8000 x20: ffff8007b9066ac0 x19: ffff8007bae97578 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff8007a4ce4000 x7 : 0000000000000000 x6 : 000000000000003f x5 : ffff000000e6a280 x4 : ffff8007a4ce3000 x3 : 0000000000000000 x2 : aaaaaaaaaaaaaaab x1 : ffff8007b9066a10 x0 : ffff8007baff8000 Call trace: hw_stat_port_show+0x4c/0x80 [ib_core] port_attr_show+0x40/0x58 [ib_core] sysfs_kf_seq_show+0x8c/0x150 kernfs_seq_show+0x44/0x50 seq_read+0x1b4/0x45c kernfs_fop_read+0x148/0x1d8 __vfs_read+0x58/0x180 vfs_read+0x94/0x154 ksys_read+0x68/0xd8 __arm64_sys_read+0x28/0x34 el0_svc_common+0x88/0x18c el0_svc_handler+0x78/0x94 el0_svc+0x8/0xe8 Code: f2955562 aa1603e4 aa1503e0 f9405683 (f9402861)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50478 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()Patch series "nilfs2: fix UBSAN shift-out-of-bounds warnings on mounttime".The first patch fixes a bug reported by syzbot, and the second one fixesthe remaining bug of the same kind. Although they are triggered by thesame super block data anomaly, I divided it into the above two because thedetails of the issues and how to fix it are different.Both are required to eliminate the shift-out-of-bounds issues at mounttime.This patch (of 2):If the block size exponent information written in an on-disk superblock iscorrupted, nilfs_sb2_bad_offset helper function can triggershift-out-of-bounds warning followed by a kernel panic (if panic_on_warnis set): shift exponent 38983 is too large for 64-bit type 'unsigned long long' Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106 ubsan_epilogue lib/ubsan.c:151 [inline] __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322 nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline] nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523 init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577 nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047 nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317 ...In addition, since nilfs_sb2_bad_offset() performs multiplication withoutconsidering the upper bound, the computation may overflow if the disklayout parameters are not normal.This fixes these issues by inserting preliminary sanity checks for thoseparameters and by converting the comparison from one involvingmultiplication and left bit-shifting to one using division and rightbit-shifting.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50481 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: fix possible null-ptr-deref in cxl_guest_init_afu|adapter()If device_register() fails in cxl_register_afu|adapter(), the deviceis not added, device_unregister() can not be called in the error path,otherwise it will cause a null-ptr-deref because of removing not addeddevice.As comment of device_register() says, it should use put_device() to giveup the reference in the error path. So split device_unregister() intodevice_del() and put_device(), then goes to put dev when register fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50484 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential memory leaksWhen the driver hits -ENOMEM at allocating a URB or a buffer, itaborts and goes to the error path that releases the all previouslyallocated resources. However, when -ENOMEM hits at the middle of thesync EP URB allocation loop, the partially allocated URBs might beleft without released, because ep->nurbs is still zero at that point.Fix it by setting ep->nurbs at first, so that the error handler loopsover the full URB list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50494 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel_powerclamp: Use get_cpu() instead of smp_processor_id() to avoid crashWhen CPU 0 is offline and intel_powerclamp is used to injectidle, it generates kernel BUG:BUG: using smp_processor_id() in preemptible [00000000] code: bash/15687caller is debug_smp_processor_id+0x17/0x20CPU: 4 PID: 15687 Comm: bash Not tainted 5.19.0-rc7+ #57Call Trace:dump_stack_lvl+0x49/0x63dump_stack+0x10/0x16check_preemption_disabled+0xdd/0xe0debug_smp_processor_id+0x17/0x20powerclamp_set_cur_state+0x7f/0xf9 [intel_powerclamp]......Here CPU 0 is the control CPU by default and changed to the current CPU,if CPU 0 offlined. This check has to be performed under cpus_read_lock(),hence the above warning.Use get_cpu() instead of smp_processor_id() to avoid this BUG.[ rjw: Subject edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50500 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix memory leak in nsim_drv_probe() when nsim_dev_resources_register() failedIf some items in nsim_dev_resources_register() fail, memory leak willoccur. The following is the memory leak information.unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloc_trace+0x22/0x60 [<0000000027384c69>] devl_resource_register+0x144/0x4e0 [<00000000a16db248>] nsim_drv_probe+0x37a/0x1260 [<000000007d1f448c>] really_probe+0x20b/0xb10 [<00000000c416848a>] __driver_probe_device+0x1b3/0x4a0 [<00000000077e0351>] driver_probe_device+0x49/0x140 [<0000000054f2465a>] __device_attach_driver+0x18c/0x2a0 [<000000008538f359>] bus_for_each_drv+0x151/0x1d0 [<0000000038e09747>] __device_attach+0x1c9/0x4e0 [<00000000dd86e533>] bus_probe_device+0x1d5/0x280 [<00000000839bea35>] device_add+0xae0/0x1cb0 [<000000009c2abf46>] new_device_store+0x3b6/0x5f0 [<00000000fb823d7f>] bus_attr_store+0x72/0xa0 [<000000007acc4295>] sysfs_kf_write+0x106/0x160 [<000000005f50cb4d>] kernfs_fop_write_iter+0x3a8/0x5a0 [<0000000075eb41bf>] vfs_write+0x8f0/0xc80

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50501 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for dcoda_iram_allocAs the coda_iram_alloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50503 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: lpddr2_nvm: Fix possible null-ptr-derefIt will cause null-ptr-deref when resource_size(add_range) invoked,if platform_get_resource() returns NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50504 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/rtas: avoid scheduling in rtas_os_term()It's unsafe to use rtas_busy_delay() to handle a busy status fromthe ibm,os-term RTAS function in rtas_os_term():Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000bBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 2, expected: 0CPU: 7 PID: 1 Comm: swapper/0 Tainted: G D 6.0.0-rc5-02182-gf8553a572277-dirty #9Call Trace:[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200Use rtas_busy_delay_time() instead, which signals without side effectswhether to attempt the ibm,os-term RTAS call again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50505 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix pci device refcount leak in ppr_notifier()As comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put(). So call it before returning from ppr_notifier()to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: coda: Add check for kmallocAs the kmalloc may return NULL pointer,it should be better to check the return valuein order to avoid NULL poineter dereference,same as the others.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50510 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/smmuv3: Fix hotplug callback leak in arm_smmu_pmu_init()arm_smmu_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50511 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:lib/fonts: fix undefined behavior in bit shift for get_default_fontShifting signed 32-bit value by 31 bits is undefined, so changingsignificant bit to unsigned. The UBSAN warning calltrace like below:UBSAN: shift-out-of-bounds in lib/fonts/fonts.c:139:20left shift of 1 by 31 places cannot be represented in type 'int' dump_stack_lvl+0x7d/0xa5 dump_stack+0x15/0x1b ubsan_epilogue+0xe/0x4e __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c get_default_font+0x1c7/0x1f0 fbcon_startup+0x347/0x3a0 do_take_over_console+0xce/0x270 do_fbcon_takeover+0xa1/0x170 do_fb_registered+0x2a8/0x340 fbcon_fb_registered+0x47/0xe0 register_framebuffer+0x294/0x4a0 __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper] drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper] drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper] drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper] bochs_pci_probe+0x6ca/0x772 [bochs] local_pci_probe+0x4d/0xb0 pci_device_probe+0x119/0x320 really_probe+0x181/0x550 __driver_probe_device+0xc6/0x220 driver_probe_device+0x32/0x100 __driver_attach+0x195/0x200 bus_for_each_dev+0xbb/0x120 driver_attach+0x27/0x30 bus_add_driver+0x22e/0x2f0 driver_register+0xa9/0x190 __pci_register_driver+0x90/0xa0 bochs_pci_driver_init+0x52/0x1000 [bochs] do_one_initcall+0x76/0x430 do_init_module+0x61/0x28a load_module+0x1f82/0x2e50 __do_sys_finit_module+0xf8/0x190 __x64_sys_finit_module+0x23/0x30 do_syscall_64+0x58/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50512 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix potential memory leak in ext4_fc_record_regions()As krealloc may return NULL, in this case 'state->fc_regions' may not befreed by krealloc, but 'state->fc_regions' already set NULL. Then willlead to 'state->fc_regions' memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50514 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: fix refcount leak on error pathWhen failing to allocate report_desc, opts->refcnt has already beenincremented so it needs to be decremented to avoid leaving the optionsstructure permanently locked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: dlm: fix invalid derefence of sb_lvbptrI experience issues when putting a lkbsb on the stack and have sb_lvbptrfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crashwith the following kernel message, the dangled pointer is here0xdeadbeef as example:[ 102.749317] BUG: unable to handle page fault for address: 00000000deadbeef[ 102.749320] #PF: supervisor read access in kernel mode[ 102.749323] #PF: error_code(0x0000) - not-present page[ 102.749325] PGD 0 P4D 0[ 102.749332] Oops: 0000 [#1] PREEMPT SMP PTI[ 102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G W 5.19.0-rc3+ #1565[ 102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014[ 102.749344] RIP: 0010:memcpy_erms+0x6/0x10[ 102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe[ 102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202[ 102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040[ 102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070[ 102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001[ 102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70[ 102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001[ 102.749368] FS: 0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000[ 102.749372] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0[ 102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 102.749379] PKRU: 55555554[ 102.749381] Call Trace:[ 102.749382] [ 102.749383] ? send_args+0xb2/0xd0[ 102.749389] send_common+0xb7/0xd0[ 102.749395] _unlock_lock+0x2c/0x90[ 102.749400] unlock_lock.isra.56+0x62/0xa0[ 102.749405] dlm_unlock+0x21e/0x330[ 102.749411] ? lock_torture_stats+0x80/0x80 [dlm_locktorture][ 102.749416] torture_unlock+0x5a/0x90 [dlm_locktorture][ 102.749419] ? preempt_count_sub+0xba/0x100[ 102.749427] lock_torture_writer+0xbd/0x150 [dlm_locktorture][ 102.786186] kthread+0x10a/0x130[ 102.786581] ? kthread_complete_and_exit+0x20/0x20[ 102.787156] ret_from_fork+0x22/0x30[ 102.787588] [ 102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw[ 102.792536] CR2: 00000000deadbeef[ 102.792930] ---[ end trace 0000000000000000 ]---This patch fixes the issue by checking also on DLM_LKF_VALBLK on exflagsis set when copying the lvbptr array instead of if it's just null whichfixes for me the issue.I think this patch can fix other dlm users as well, depending how theyhandle the init, freeing memory handling of sb_lvbptr and don't setDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be ahidden issue all the time. However with checking on DLM_LKF_VALBLK theuser always need to provide a sb_lvbptr non-null value. There might bemore intelligent handling between per ls lvblen, DLM_LKF_VALBLK andnon-null to report the user the way how DLM API is used is wrong but canbe added for later, this will only fix the current behaviour.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50520 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()As comment of pci_get_class() says, it returns a pci_device with itsrefcount increased and decreased the refcount for the input parameter@from if it is not NULL.If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, weneed to call pci_dev_put() to decrease the refcount. Add the missingpci_dev_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50521 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: mxm-wmi: fix memleak in mxm_wmi_call_mx[ds|mx]()The ACPI buffer memory (out.pointer) returned by wmi_evaluate_method()is not freed after the call, so it leads to memory leak.The method results in ACPI buffer is not used, so just pass NULL towmi_evaluate_method() which fixes the memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50523 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: rockchip: Fix memory leak in rockchip_clk_register_pll()If clk_register() fails, @pll->rate_table may have allocated memory bykmemdup(), so it needs to be freed, otherwise will cause memory leakissue, this patch fixes it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50525 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/fsl_pamu: Fix resource leak in fsl_pamu_probe()The fsl_pamu_probe() returns directly when create_csd() failed, leavingirq and memories unreleased.Fix by jumping to error if create_csd() returns error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50527 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix size validation for non-exclusive domains (v4)Fix amdgpu_bo_validate_size() to check whether the TTM domain manager for therequested memory exists, else we get a kernel oops when dereferencing "man".v2: Make the patch standalone, i.e. not dependent on local patches.v3: Preserve old behaviour and just check that the manager pointer is not NULL.v4: Complain if GTT domain requested and it is uninitialized--most likely a bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50528 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix memory leakageThis patch fixes potential memory leakage and seg faultin _gpuvm_import_dmabuf() function

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50529 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:test_firmware: fix memory leak in test_firmware_init()When misc_register() failed in test_firmware_init(), the memory pointedby test_fw_config->name is not released. The memory leak information isas follows:unreferenced object 0xffff88810a34cb00 (size 32): comm "insmod", pid 7952, jiffies 4294948236 (age 49.060s) hex dump (first 32 bytes): 74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69 test-firmware.bi 6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 n............... backtrace: [] __kmalloc_node_track_caller+0x4b/0xc0 [] kstrndup+0x46/0xc0 [] __test_firmware_config_init+0x29/0x380 [test_firmware] [] 0xffffffffa040f068 [] do_one_initcall+0x141/0x780 [] do_init_module+0x1c3/0x630 [] load_module+0x623e/0x76a0 [] __do_sys_finit_module+0x181/0x240 [] do_syscall_64+0x39/0xb0 [] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50530 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()Our syzkaller report a null pointer dereference, root cause isfollowing:__blk_mq_alloc_map_and_rqs set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs blk_mq_alloc_map_and_rqs blk_mq_alloc_rqs // failed due to oom alloc_pages_node // set->tags[hctx_idx] is still NULL blk_mq_free_rqs drv_tags = set->tags[hctx_idx]; // null pointer dereference is triggered blk_mq_clear_rq_mapping(drv_tags, ...)This is because commit 63064be150e4 ("blk-mq:Add blk_mq_alloc_map_and_rqs()") merged the two steps:1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])into one step:set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()Since tags is not initialized yet in this case, fix the problem bychecking if tags is NULL pointer in blk_mq_clear_rq_mapping().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50531 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix an information leak in tipc_topsrv_kern_subscrUse a 8-byte write to initialize sub.usr_handle intipc_topsrv_kern_subscr(), otherwise four bytes remain uninitializedwhen issuing setsockopt(..., SOL_TIPC, ...).This resulted in an infoleak reported by KMSAN when the packet wasreceived: ===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169 instrument_copy_to_user ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/iov_iter.c:169 _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527 copy_to_iter ./include/linux/uio.h:176 simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419 skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527 skb_copy_datagram_msg ./include/linux/skbuff.h:3903 packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469 ____sys_recvmsg+0x2c4/0x810 net/socket.c:? ___sys_recvmsg+0x217/0x840 net/socket.c:2743 __sys_recvmsg net/socket.c:2773 __do_sys_recvmsg net/socket.c:2783 __se_sys_recvmsg net/socket.c:2780 __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 ... Uninit was stored to memory at: tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375 tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084 tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201 __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252 __do_sys_setsockopt net/socket.c:2263 __se_sys_setsockopt net/socket.c:2260 __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260 do_syscall_x64 arch/x86/entry/common.c:50 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120 Local variable sub created at: tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562 tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190 Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50532 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,sas_rphy_free() needs be called to free the resource allocated insas_end_device_alloc(). Otherwise a kernel crash will happen:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000108CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G W 6.1.0-rc1+ #189pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : device_del+0x54/0x3d0lr : device_del+0x37c/0x3d0Call trace: device_del+0x54/0x3d0 attribute_container_class_device_del+0x28/0x38 transport_remove_classdev+0x6c/0x80 attribute_container_device_trigger+0x108/0x110 transport_remove_device+0x28/0x38 sas_rphy_remove+0x50/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_rphy_remove+0x38/0x78 [scsi_transport_sas] sas_port_delete+0x30/0x148 [scsi_transport_sas] do_sas_phy_delete+0x78/0x80 [scsi_transport_sas] device_for_each_child+0x68/0xb0 sas_remove_children+0x30/0x50 [scsi_transport_sas] sas_remove_host+0x20/0x38 [scsi_transport_sas] scsih_remove+0xd8/0x420 [mpt3sas]Because transport_add_device() is not called when sas_rphy_add() fails, thedevice is not added. When sas_rphy_remove() is subsequently called toremove the device in the remove() path, a NULL pointer dereference happens.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50534 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Use last transaction's pmd->root when commit failedRecently we found a softlock up problem in dm thin pool btree lookupcode due to corrupted metadata: Kernel panic - not syncing: softlockup: hung tasks CPU: 7 PID: 2669225 Comm: kworker/u16:3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: dm-thin do_worker [dm_thin_pool] Call Trace: dump_stack+0x9c/0xd3 panic+0x35d/0x6b9 watchdog_timer_fn.cold+0x16/0x25 __run_hrtimer+0xa2/0x2d0 RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio] __bufio_new+0x11f/0x4f0 [dm_bufio] new_read+0xa3/0x1e0 [dm_bufio] dm_bm_read_lock+0x33/0xd0 [dm_persistent_data] ro_step+0x63/0x100 [dm_persistent_data] btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data] dm_btree_lookup+0x16f/0x210 [dm_persistent_data] dm_thin_find_block+0x12c/0x210 [dm_thin_pool] __process_bio_read_only+0xc5/0x400 [dm_thin_pool] process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool] process_one_work+0x3c5/0x730Following process may generate a broken btree mixed with fresh andstale btree nodes, which could get dm thin trapped in an infinite loopwhile looking up data block: Transaction 1: pmd->root = A, A->B->C // One path in btree pmd->root = X, X->Y->Z // Copy-up Transaction 2: X,Z is updated on disk, Y write failed. // Commit failed, dm thin becomes read-only. process_bio_read_only dm_thin_find_block __find_block dm_btree_lookup(pmd->root)The pmd->root points to a broken btree, Y may contain stale nodepointing to any block, for example X, which gets dm thin trapped intoa dead loop while looking up Z.Fix this by setting pmd->root in __open_metadata(), so that dm thinwill use the last transaction's pmd->root if commit failed.Fetch a reproducer in [Link].Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50535 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential null-deref in dm_resume[Why]Fixing smatch error:dm_resume() error: we previously assumed 'aconnector->dc_link' could be null[How]Check if dc_link null at the beginning of the loop,so further checks can be dropped.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50536 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix repeated calls to sock_put() when msg has more_dataIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,sock_put() will be called multiple times.We should reset the eval variable to __SK_NONE every time more_datastarts.This causes:IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110Modules linked in:CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014Call Trace: __tcp_transmit_skb+0xa1b/0xb90 ? __alloc_skb+0x8c/0x1a0 ? __kmalloc_node_track_caller+0x184/0x320 tcp_write_xmit+0x22a/0x1110 __tcp_push_pending_frames+0x32/0xf0 do_tcp_sendpages+0x62d/0x640 tcp_bpf_push+0xae/0x2c0 tcp_bpf_sendmsg_redir+0x260/0x410 ? preempt_count_add+0x70/0xa0 tcp_bpf_send_verdict+0x386/0x4b0 tcp_bpf_sendmsg+0x21b/0x3b0 sock_sendmsg+0x58/0x70 __sys_sendto+0xfa/0x170 ? xfd_validate_state+0x1d/0x80 ? switch_fpu_return+0x59/0xe0 __x64_sys_sendto+0x24/0x30 do_syscall_64+0x37/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50537 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' willnot be freed through rpi_firmware_delete(), fix this leak by callingkfree() in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50544 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()xhci_alloc_stream_info() allocates stream context array for stream_info->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,stream_info->stream_ctx_array is not released, which will lead to amemory leak.We can fix it by releasing the stream_info->stream_ctx_array withxhci_free_stream_ctx() on the error path to avoid the potential memoryleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50545 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r6040: Fix kmemleak in probe and removeThere is a memory leaks reported by kmemleak: unreferenced object 0xffff888116111000 (size 2048): comm "modprobe", pid 817, jiffies 4294759745 (age 76.502s) hex dump (first 32 bytes): 00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff ................ 08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00 ................ backtrace: [] kmalloc_trace+0x22/0x60 [] phy_device_create+0x4e/0x90 [] get_phy_device+0xd2/0x220 [] mdiobus_scan+0xa4/0x2e0 [] __mdiobus_register+0x482/0x8b0 [] r6040_init_one+0x714/0xd2c [r6040] ...The problem occurs in probe process as follows: r6040_init_one: mdiobus_register mdiobus_scan <- alloc and register phy_device, the reference count of phy_device is 3 r6040_mii_probe phy_connect <- connect to the first phy_device, so the reference count of the first phy_device is 4, others are 3 register_netdev <- fault inject succeeded, goto error handling path // error handling path err_out_mdio_unregister: mdiobus_unregister(lp->mii_bus); err_out_mdio: mdiobus_free(lp->mii_bus); <- the reference count of the first phy_device is 1, it is not released and other phy_devices are released // similarly, the remove process also has the same problemThe root cause is traced to the phy_device is not disconnected whenremoves one r6040 device in r6040_remove_one() or on error handling pathafter r6040_mii probed successfully. In r6040_mii_probe(), a net ethernetdevice is connected to the first PHY device of mii_bus, in order tonotify the connected driver when the link status changes, which is thedefault behavior of the PHY infrastructure to handle everything.Therefore the phy_device should be disconnected when removes one r6040device or on error handling path.Fix it by adding phy_disconnect() when removes one r6040 device or onerror handling path after r6040_mii probed successfully.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50546 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninititialized value in 'ext4_evict_inode'Syzbot found the following issue:=====================================================BUG: KMSAN: uninit-value in ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 ext4_evict_inode+0xdd/0x26b0 fs/ext4/inode.c:180 evict+0x365/0x9a0 fs/inode.c:664 iput_final fs/inode.c:1747 [inline] iput+0x985/0xdd0 fs/inode.c:1773 __ext4_new_inode+0xe54/0x7ec0 fs/ext4/ialloc.c:1361 ext4_mknod+0x376/0x840 fs/ext4/namei.c:2844 vfs_mknod+0x79d/0x830 fs/namei.c:3914 do_mknodat+0x47d/0xaa0 __do_sys_mknodat fs/namei.c:3992 [inline] __se_sys_mknodat fs/namei.c:3989 [inline] __ia32_sys_mknodat+0xeb/0x150 fs/namei.c:3989 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: __alloc_pages+0x9f1/0xe80 mm/page_alloc.c:5578 alloc_pages+0xaae/0xd80 mm/mempolicy.c:2285 alloc_slab_page mm/slub.c:1794 [inline] allocate_slab+0x1b5/0x1010 mm/slub.c:1939 new_slab mm/slub.c:1992 [inline] ___slab_alloc+0x10c3/0x2d60 mm/slub.c:3180 __slab_alloc mm/slub.c:3279 [inline] slab_alloc_node mm/slub.c:3364 [inline] slab_alloc mm/slub.c:3406 [inline] __kmem_cache_alloc_lru mm/slub.c:3413 [inline] kmem_cache_alloc_lru+0x6f3/0xb30 mm/slub.c:3429 alloc_inode_sb include/linux/fs.h:3117 [inline] ext4_alloc_inode+0x5f/0x860 fs/ext4/super.c:1321 alloc_inode+0x83/0x440 fs/inode.c:259 new_inode_pseudo fs/inode.c:1018 [inline] new_inode+0x3b/0x430 fs/inode.c:1046 __ext4_new_inode+0x2a7/0x7ec0 fs/ext4/ialloc.c:959 ext4_mkdir+0x4d5/0x1560 fs/ext4/namei.c:2992 vfs_mkdir+0x62a/0x870 fs/namei.c:4035 do_mkdirat+0x466/0x7b0 fs/namei.c:4060 __do_sys_mkdirat fs/namei.c:4075 [inline] __se_sys_mkdirat fs/namei.c:4073 [inline] __ia32_sys_mkdirat+0xc4/0x120 fs/namei.c:4073 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1b/0x20 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82CPU: 1 PID: 4625 Comm: syz-executor.2 Not tainted 6.1.0-rc4-syzkaller-62821-gcb231e2f67ec #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022=====================================================Now, 'ext4_alloc_inode()' didn't init 'ei->i_flags'. If new inode failedbefore set 'ei->i_flags' in '__ext4_new_inode()', then do 'iput()'. As after6bc0d63dad7f commit will access 'ei->i_flags' in 'ext4_evict_inode()' whichwill lead to access uninit-value.To solve above issue just init 'ei->i_flags' in 'ext4_alloc_inode()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadataFollowing concurrent processes: P1(drop cache) P2(kworker)drop_caches_sysctl_handler drop_slab shrink_slab down_read(&shrinker_rwsem) - LOCK A do_shrink_slab super_cache_scan prune_icache_sb dispose_list evict ext4_evict_inode ext4_clear_inode ext4_discard_preallocations ext4_mb_load_buddy_gfp ext4_mb_init_cache ext4_read_block_bitmap_nowait ext4_read_bh_nowait submit_bh dm_submit_bio do_worker process_deferred_bios commit metadata_operation_failed dm_pool_abort_metadata down_write(&pmd->root_lock) - LOCK B __destroy_persistent_data_objects dm_block_manager_destroy dm_bufio_client_destroy unregister_shrinker down_write(&shrinker_rwsem) thin_map | dm_thin_find_block v down_read(&pmd->root_lock) --> ABBA deadlock, which triggers hung task:[ 76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.[ 76.976019] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.978521] task:kworker/u4:3 state:D stack:0 pid:63 ppid:2[ 76.978534] Workqueue: dm-thin do_worker[ 76.978552] Call Trace:[ 76.978564] __schedule+0x6ba/0x10f0[ 76.978582] schedule+0x9d/0x1e0[ 76.978588] rwsem_down_write_slowpath+0x587/0xdf0[ 76.978600] down_write+0xec/0x110[ 76.978607] unregister_shrinker+0x2c/0xf0[ 76.978616] dm_bufio_client_destroy+0x116/0x3d0[ 76.978625] dm_block_manager_destroy+0x19/0x40[ 76.978629] __destroy_persistent_data_objects+0x5e/0x70[ 76.978636] dm_pool_abort_metadata+0x8e/0x100[ 76.978643] metadata_operation_failed+0x86/0x110[ 76.978649] commit+0x6a/0x230[ 76.978655] do_worker+0xc6e/0xd90[ 76.978702] process_one_work+0x269/0x630[ 76.978714] worker_thread+0x266/0x630[ 76.978730] kthread+0x151/0x1b0[ 76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.[ 76.979756] Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910[ 76.982111] task:test.sh state:D stack:0 pid:2646 ppid:2459[ 76.982128] Call Trace:[ 76.982139] __schedule+0x6ba/0x10f0[ 76.982155] schedule+0x9d/0x1e0[ 76.982159] rwsem_down_read_slowpath+0x4f4/0x910[ 76.982173] down_read+0x84/0x170[ 76.982177] dm_thin_find_block+0x4c/0xd0[ 76.982183] thin_map+0x201/0x3d0[ 76.982188] __map_bio+0x5b/0x350[ 76.982195] dm_submit_bio+0x2b6/0x930[ 76.982202] __submit_bio+0x123/0x2d0[ 76.982209] submit_bio_noacct_nocheck+0x101/0x3e0[ 76.982222] submit_bio_noacct+0x389/0x770[ 76.982227] submit_bio+0x50/0xc0[ 76.982232] submit_bh_wbc+0x15e/0x230[ 76.982238] submit_bh+0x14/0x20[ 76.982241] ext4_read_bh_nowait+0xc5/0x130[ 76.982247] ext4_read_block_bitmap_nowait+0x340/0xc60[ 76.982254] ext4_mb_init_cache+0x1ce/0xdc0[ 76.982259] ext4_mb_load_buddy_gfp+0x987/0xfa0[ 76.982263] ext4_discard_preallocations+0x45d/0x830[ 76.982274] ext4_clear_inode+0x48/0xf0[ 76.982280] ext4_evict_inode+0xcf/0xc70[ 76.982285] evict+0x119/0x2b0[ 76.982290] dispose_list+0x43/0xa0[ 76.982294] prune_icache_sb+0x64/0x90[ 76.982298] super_cache_scan+0x155/0x210[ 76.982303] do_shrink_slab+0x19e/0x4e0[ 76.982310] shrink_slab+0x2bd/0x450[ 76.982317] drop_slab+0xcc/0x1a0[ 76.982323] drop_caches_sysctl_handler+0xb7/0xe0[ 76.982327] proc_sys_call_handler+0x1bc/0x300[ 76.982331] proc_sys_write+0x17/0x20[ 76.982334] vfs_write+0x3d3/0x570[ 76.982342] ksys_write+0x73/0x160[ 76.982347] __x64_sys_write+0x1e/0x30[ 76.982352] do_syscall_64+0x35/0x80[ 76.982357] entry_SYSCALL_64_after_hwframe+0x63/0xcdFunct---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50550 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iolatency: Fix memory leak on add_disk() failuresWhen a gendisk is successfully initialized but add_disk() fails such as whena loop device has invalid number of minor device numbers specified,blkcg_init_disk() is called during init and then blkcg_exit_disk() duringerror handling. Unfortunately, iolatency gets initialized in the former butdoesn't get cleaned up in the latter.This is because, in non-error cases, the cleanup is performed bydel_gendisk() calling rq_qos_exit(), the assumption being that rq_qospolicies, iolatency being one of them, can only be activated once the diskis fully registered and visible. That assumption is true for wbt and iocost,but not so for iolatency as it gets initialized before add_disk() is called.It is desirable to lazy-init rq_qos policies because they are optionalfeatures and add to hot path overhead once initialized - each IO has to walkall the registered rq_qos policies. So, we want to switch iolatency to lazyinit too. However, that's a bigger change. As a fix for the immediateproblem, let's just add an extra call to rq_qos_exit() in blkcg_exit_disk().This is safe because duplicate calls to rq_qos_exit() become noop's.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50551 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix potential shift-out-of-bounds in brcmf_fw_alloc_request()This patch fixes a shift-out-of-bounds in brcmfmac that occurs inBIT(chiprev) when a 'chiprev' provided by the device is too large.It should also not be equal to or greater than BITS_PER_TYPE(u32)as we do bitwise AND with a u32 variable and BIT(chiprev). The patchadds a check that makes the function return NULL if that is the case.Note that the NULL case is later handled by the bus-specific caller,brcmf_usb_probe_cb() or brcmf_usb_reset_resume(), for example.Found by a modified version of syzkaller.UBSAN: shift-out-of-bounds in drivers/net/wireless/broadcom/brcm80211/brcmfmac/firmware.cshift exponent 151055786 is too large for 64-bit type 'long unsigned int'CPU: 0 PID: 1885 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014Workqueue: usb_hub_wq hub_eventCall Trace: dump_stack_lvl+0x57/0x7d ubsan_epilogue+0x5/0x40 __ubsan_handle_shift_out_of_bounds.cold+0x53/0xdb ? lock_chain_count+0x20/0x20 brcmf_fw_alloc_request.cold+0x19/0x3ea ? brcmf_fw_get_firmwares+0x250/0x250 ? brcmf_usb_ioctl_resp_wait+0x1a7/0x1f0 brcmf_usb_get_fwname+0x114/0x1a0 ? brcmf_usb_reset_resume+0x120/0x120 ? number+0x6c4/0x9a0 brcmf_c_process_clm_blob+0x168/0x590 ? put_dec+0x90/0x90 ? enable_ptr_key_workfn+0x20/0x20 ? brcmf_common_pd_remove+0x50/0x50 ? rcu_read_lock_sched_held+0xa1/0xd0 brcmf_c_preinit_dcmds+0x673/0xc40 ? brcmf_c_set_joinpref_default+0x100/0x100 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lock_acquire+0x19d/0x4e0 ? find_held_lock+0x2d/0x110 ? brcmf_usb_deq+0x1cc/0x260 ? mark_held_locks+0x9f/0xe0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? _raw_spin_unlock_irqrestore+0x47/0x50 ? trace_hardirqs_on+0x1c/0x120 ? brcmf_usb_deq+0x1a7/0x260 ? brcmf_usb_rx_fill_all+0x5a/0xf0 brcmf_attach+0x246/0xd40 ? wiphy_new_nm+0x1476/0x1d50 ? kmemdup+0x30/0x40 brcmf_usb_probe+0x12de/0x1690 ? brcmf_usbdev_qinit.constprop.0+0x470/0x470 usb_probe_interface+0x25f/0x710 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 ? usb_match_id.part.0+0x88/0xc0 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __mutex_unlock_slowpath+0xe7/0x660 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_set_configuration+0x984/0x1770 ? kernfs_create_link+0x175/0x230 usb_generic_driver_probe+0x69/0x90 usb_probe_device+0x9c/0x220 really_probe+0x1be/0xa90 __driver_probe_device+0x2ab/0x460 driver_probe_device+0x49/0x120 __device_attach_driver+0x18a/0x250 ? driver_allows_async_probing+0x120/0x120 bus_for_each_drv+0x123/0x1a0 ? bus_rescan_devices+0x20/0x20 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 ? trace_hardirqs_on+0x1c/0x120 __device_attach+0x207/0x330 ? device_bind_driver+0xb0/0xb0 ? kobject_uevent_env+0x230/0x12c0 bus_probe_device+0x1a2/0x260 device_add+0xa61/0x1ce0 ? __fw_devlink_link_to_suppliers+0x550/0x550 usb_new_device.cold+0x463/0xf66 ? hub_disconnect+0x400/0x400 ? _raw_spin_unlock_irq+0x24/0x30 hub_event+0x10d5/0x3330 ? hub_port_debounce+0x280/0x280 ? __lock_acquire+0x1671/0x5790 ? wq_calc_node_cpumask+0x170/0x2a0 ? lock_release+0x640/0x640 ? rcu_read_lock_sched_held+0xa1/0xd0 ? rcu_read_lock_bh_held+0xb0/0xb0 ? lockdep_hardirqs_on_prepare+0x273/0x3e0 process_one_work+0x873/0x13e0 ? lock_release+0x640/0x640 ? pwq_dec_nr_in_flight+0x320/0x320 ? rwlock_bug.part.0+0x90/0x90 worker_thread+0x8b/0xd10 ? __kthread_parkme+0xd9/0x1d0 ? pr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50553 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'When generate a synthetic event with many params and then create a traceaction for it [1], kernel panic happened [2].It is because that in trace_action_create() 'data->n_params' is up toSYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'keeps indices into array 'hist_data->var_refs' for each synthetic eventparam, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX(current value is 16), so out-of-bound write happened when 'data->n_params'more than 16. In this case, 'data->match_data.event' is overwritten andeventually cause the panic.To solve the issue, adjust the length of 'data->var_ref_idx' to beSYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.[1] # cd /sys/kernel/tracing/ # echo "my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\int v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\int v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\int v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\int v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\int v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\int v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\int v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\int v63" >> synthetic_events # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm=="bash"' >> \events/sched/sched_waking/trigger # echo "hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\pid,pid,pid,pid,pid,pid,pid,pid,pid)" >> events/sched/sched_switch/trigger[2]BUG: unable to handle page fault for address: ffff91c900000000PGD 61001067 P4D 61001067 PUD 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 2 PID: 322 Comm: bash Tainted: G W 6.1.0-rc8+ #229Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:strcmp+0xc/0x30Code: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 eec3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 1407 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3RSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000RBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000R10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580R13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538FS: 00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0Call Trace: __find_event_file+0x55/0x90 action_create+0x76c/0x1060 event_hist_trigger_parse+0x146d/0x2060 ? event_trigger_write+0x31/0xd0 trigger_process_regex+0xbb/0x110 event_trigger_write+0x6b/0xd0 vfs_write+0xc8/0x3e0 ? alloc_fd+0xc0/0x160 ? preempt_count_add+0x4d/0xa0 ? preempt_count_add+0x70/0xa0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f1d1d0cf077Code: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1efa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74RSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077RDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001RBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142R---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50555 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix a null-ptr-deref in tipc_topsrv_acceptsyzbot found a crash in tipc_topsrv_accept: KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipc_rcv tipc_topsrv_accept RIP: 0010:kernel_accept+0x22d/0x350 net/socket.c:3487 Call Trace: tipc_topsrv_accept+0x197/0x280 net/tipc/topsrv.c:460 process_one_work+0x991/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306It was caused by srv->listener that might be set to null bytipc_topsrv_stop() in net .exit whereas it's still used intipc_topsrv_accept() worker.srv->listener is protected by srv->idr_lock in tipc_topsrv_stop(), so adda check for srv->listener under srv->idr_lock in tipc_topsrv_accept() toavoid the null-ptr-deref. To ensure the lsock is not released during thetipc_topsrv_accept(), move sock_release() after tipc_topsrv_work_stop()where it's waiting until the tipc_topsrv_accept worker to be done.Note that sk_callback_lock is used to protect sk->sk_user_data instead ofsrv->listener, and it should check srv in tipc_topsrv_listener_data_ready()instead. This also ensures that no more tipc_topsrv_accept worker will bestarted after tipc_conn_close() is called in tipc_topsrv_stop() where itsets sk->sk_user_data to null.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50556 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: Fix potential null-ptr-deref due to drmm_mode_config_init()drmm_mode_config_init() will call drm_mode_create_standard_properties()and won't check the ret value. When drm_mode_create_standard_properties()failed due to alloc, property will be a NULL pointer and may causes thenull-ptr-deref. Fix the null-ptr-deref by adding the ret value check.Found null-ptr-deref while testing insert module bochs:general protection fault, probably for non-canonical address 0xdffffc000000000c: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]Call Trace: __drm_connector_init+0xb6c/0x1100 [drm] bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs] pci_device_probe+0x17d/0x340 really_probe+0x1db/0x5d0 __driver_probe_device+0x1e7/0x250 driver_probe_device+0x4a/0x120 __driver_attach+0xcd/0x2c0 bus_for_each_dev+0x11a/0x1b0 bus_add_driver+0x3d7/0x500 driver_register+0x18e/0x320 do_one_initcall+0xc4/0x3e0 do_init_module+0x1b4/0x630 load_module+0x5dca/0x7230 __do_sys_finit_module+0x100/0x170 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7ff65af9f839

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: scu: fix memleak on platform_device_add() failsNo error handling is performed when platform_device_add()fails. Add error processing before return, and modifiedthe return value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: explicitly remove aggregate driver at module unload timeBecause component_master_del wasn't being called when unloading themeson_drm module, the aggregate device would linger forever in the globalaggregate_devices list. That means when unloading and reloading themeson_dw_hdmi module, component_add would call intotry_to_bring_up_aggregate_device and find the unbound meson_drm aggregatedevice.This would in turn dereference some of the aggregate_device's structentries which point to memory automatically freed by the devres API whenunbinding the aggregate device from meson_drv_unbind, and trigger anuse-after-free bug:[ +0.000014] =============================================================[ +0.000007] BUG: KASAN: use-after-free in find_components+0x468/0x500[ +0.000017] Read of size 8 at addr ffff000006731688 by task modprobe/2536[ +0.000018] CPU: 4 PID: 2536 Comm: modprobe Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1[ +0.000010] Hardware name: Hardkernel ODROID-N2Plus (DT)[ +0.000008] Call trace:[ +0.000005] dump_backtrace+0x1ec/0x280[ +0.000011] show_stack+0x24/0x80[ +0.000007] dump_stack_lvl+0x98/0xd4[ +0.000010] print_address_description.constprop.0+0x80/0x520[ +0.000011] print_report+0x128/0x260[ +0.000007] kasan_report+0xb8/0xfc[ +0.000007] __asan_report_load8_noabort+0x3c/0x50[ +0.000009] find_components+0x468/0x500[ +0.000008] try_to_bring_up_aggregate_device+0x64/0x390[ +0.000009] __component_add+0x1dc/0x49c[ +0.000009] component_add+0x20/0x30[ +0.000008] meson_dw_hdmi_probe+0x28/0x34 [meson_dw_hdmi][ +0.000013] platform_probe+0xd0/0x220[ +0.000008] really_probe+0x3ac/0xa80[ +0.000008] __driver_probe_device+0x1f8/0x400[ +0.000008] driver_probe_device+0x68/0x1b0[ +0.000008] __driver_attach+0x20c/0x480[ +0.000009] bus_for_each_dev+0x114/0x1b0[ +0.000007] driver_attach+0x48/0x64[ +0.000009] bus_add_driver+0x390/0x564[ +0.000007] driver_register+0x1a8/0x3e4[ +0.000009] __platform_driver_register+0x6c/0x94[ +0.000007] meson_dw_hdmi_platform_driver_init+0x30/0x1000 [meson_dw_hdmi][ +0.000014] do_one_initcall+0xc4/0x2b0[ +0.000008] do_init_module+0x154/0x570[ +0.000010] load_module+0x1a78/0x1ea4[ +0.000008] __do_sys_init_module+0x184/0x1cc[ +0.000008] __arm64_sys_init_module+0x78/0xb0[ +0.000008] invoke_syscall+0x74/0x260[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260[ +0.000009] do_el0_svc+0x50/0x70[ +0.000008] el0_svc+0x68/0x1a0[ +0.000009] el0t_64_sync_handler+0x11c/0x150[ +0.000009] el0t_64_sync+0x18c/0x190[ +0.000014] Allocated by task 902:[ +0.000007] kasan_save_stack+0x2c/0x5c[ +0.000009] __kasan_kmalloc+0x90/0xd0[ +0.000007] __kmalloc_node+0x240/0x580[ +0.000010] memcg_alloc_slab_cgroups+0xa4/0x1ac[ +0.000010] memcg_slab_post_alloc_hook+0xbc/0x4c0[ +0.000008] kmem_cache_alloc_node+0x1d0/0x490[ +0.000009] __alloc_skb+0x1d4/0x310[ +0.000010] alloc_skb_with_frags+0x8c/0x620[ +0.000008] sock_alloc_send_pskb+0x5ac/0x6d0[ +0.000010] unix_dgram_sendmsg+0x2e0/0x12f0[ +0.000010] sock_sendmsg+0xcc/0x110[ +0.000007] sock_write_iter+0x1d0/0x304[ +0.000008] new_sync_write+0x364/0x460[ +0.000007] vfs_write+0x420/0x5ac[ +0.000008] ksys_write+0x19c/0x1f0[ +0.000008] __arm64_sys_write+0x78/0xb0[ +0.000007] invoke_syscall+0x74/0x260[ +0.000008] el0_svc_common.constprop.0+0x1a8/0x260[ +0.000009] do_el0_svc+0x50/0x70[ +0.000007] el0_svc+0x68/0x1a0[ +0.000008] el0t_64_sync_handler+0x11c/0x150[ +0.000008] el0t_64_sync+0x18c/0x190[ +0.000013] Freed by task 2509:[ +0.000008] kasan_save_stack+0x2c/0x5c[ +0.000007] kasan_set_track+0x2c/0x40[ +0.000008] kasan_set_free_info+0x28/0x50[ +0.000008] ____kasan_slab_free+0x128/0x1d4[ +0.000008] __kasan_slab_free+0x18/0x24[ +0.000007] slab_free_freelist_hook+0x108/0x230[ +0.000010] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: acpi: Call acpi_put_table() to fix memory leakThe start and length of the event log area are obtained fromTPM2 or TCPA table, so we call acpi_get_table() to get theACPI information, but the acpi_get_table() should be coupled withacpi_put_table() to release the ACPI memory, add the acpi_put_table()properly to fix the memory leak.While we are at it, remove the redundant empty line at theend of the tpm_read_log_acpi().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50564 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/netiucv: Fix return type of netiucv_tx()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/netiucv.c:1854:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = netiucv_tx, ^~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of netiucv_tx() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.Additionally, while in the area, remove a comment block that is nolonger relevant.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50568 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_hid: fix f_hidg lifetime vs cdevThe embedded struct cdev does not have its lifetime correctly tied tothe enclosing struct f_hidg, so there is a use-after-free if /dev/hidgNis held open while the gadget is deleted.This can readily be replicated with libusbgx's example programs (forconciseness - operating directly via configfs is equivalent): gadget-hid exec 3<> /dev/hidg0 gadget-vid-pid-remove exec 3<&-Pull the existing device up in to struct f_hidg and make use of thecdev_device_{add,del}() helpers. This changes the lifetime of thedevice object to match struct f_hidg, but note that it is still addedand deleted at the same time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50572 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: audio-graph-card: fix refcount leak of cpu_ep in __graph_for_each_link()The of_get_next_child() returns a node with refcount incremented, anddecrements the refcount of prev. So in the error path of the while loop,of_node_put() needs be called for cpu_ep.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50574 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/omap: dss: Fix refcount leak bugsIn dss_init_ports() and __dss_uninit_ports(), we should callof_node_put() for the reference returned by of_graph_get_port_by_id()in fail path or when it is not used anymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50624 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netsec: fix error handling in netsec_register_mdio()If phy_device_register() fails, phy_device_free() need be called toput refcount, so memory of phy device and device name can be freedin callback function.If get_phy_device() fails, mdiobus_unregister() need be called,or it will cause warning in mdiobus_free() and kobject is leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50628 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gud: Fix UBSAN warningUBSAN complains about invalid value for bool:[ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1[ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device[ 101.213426] usbcore: registered new interface driver gud[ 101.989431] ================================================================================[ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9[ 101.989447] load of value 121 is not a valid value for type '_Bool'[ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3[ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018[ 101.989459] Workqueue: events_long gud_flush_work [gud][ 101.989471] Call Trace:[ 101.989474] [ 101.989479] dump_stack_lvl+0x49/0x5f[ 101.989488] dump_stack+0x10/0x12[ 101.989493] ubsan_epilogue+0x9/0x3b[ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49[ 101.989504] dma_buf_vmap.cold+0x38/0x3d[ 101.989511] ? find_busiest_group+0x48/0x300[ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper][ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper][ 101.989535] drm_gem_vmap+0x26/0x60 [drm][ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper][ 101.989630] gud_prep_flush+0xc1/0x710 [gud][ 101.989639] ? _raw_spin_lock+0x17/0x40[ 101.989648] gud_flush_work+0x1e0/0x430 [gud][ 101.989653] ? __switch_to+0x11d/0x470[ 101.989664] process_one_work+0x21f/0x3f0[ 101.989673] worker_thread+0x200/0x3e0[ 101.989679] ? rescuer_thread+0x390/0x390[ 101.989684] kthread+0xfd/0x130[ 101.989690] ? kthread_complete_and_exit+0x20/0x20[ 101.989696] ret_from_fork+0x22/0x30[ 101.989706] [ 101.989708] ================================================================================The source of this warning is in iosys_map_clear() called fromdma_buf_vmap(). It conditionally sets values based on map->is_iomem. Theiosys_map variables are allocated uninitialized on the stack leading to->is_iomem having all kinds of values and not only 0/1.Fix this by zeroing the iosys_map variables.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cw2015: Fix potential null-ptr-deref in cw_bat_probe()cw_bat_probe() calls create_singlethread_workqueue() and not checked theret value, which may return NULL. And a null-ptr-deref may happen:cw_bat_probe() create_singlethread_workqueue() # failed, cw_bat->wq is NULL queue_delayed_work() queue_delayed_work_on() __queue_delayed_work() # warning here, but continue __queue_work() # access wq->flags, null-ptr-derefCheck the ret value and return -ENOMEM if it is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50655 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: associate skb with a device at txSyzkaller triggered flow dissector warning with the following:r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0[ 9.485929] skb_get_poff+0x53/0xa0[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20[ 9.485944] ? ppp_send_frame+0xc2/0x5b0[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0[ 9.485968] ? ppp_xmit_process+0x5b/0xb0[ 9.485974] ? ppp_write+0x12a/0x190[ 9.485981] ? do_iter_write+0x18e/0x2d0[ 9.485987] ? __import_iovec+0x30/0x130[ 9.485997] ? do_pwritev+0x1b6/0x240[ 9.486016] ? trace_hardirqs_on+0x47/0x50[ 9.486023] ? __x64_sys_pwritev+0x24/0x30[ 9.486026] ? do_syscall_64+0x3d/0x80[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcdFlow dissector tries to find skb net namespace either via deviceor via socket. Neigher is set in ppp_send_frame, so let's manuallyuse ppp->dev.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50676 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: don't hold sock lock when cancelling work from rds_tcp_reset_callbacks()syzbot is reporting lockdep warning at rds_tcp_reset_callbacks() [1], forcommit ac3615e7f3cffe2a ("RDS: TCP: Reduce code duplication inrds_tcp_reset_callbacks()") added cancel_delayed_work_sync() into a sectionprotected by lock_sock() without realizing that rds_send_xmit() might calllock_sock().We don't need to protect cancel_delayed_work_sync() using lock_sock(), foreven if rds_{send,recv}_worker() re-queued this work while __flush_work() from cancel_delayed_work_sync() was waiting for this work to complete,retried rds_{send,recv}_worker() is no-op due to the absence of RDS_CONN_UPbit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix pci device refcount leakAs comment of pci_get_domain_bus_and_slot() says, it returnsa pci device with refcount increment, when finish using it,the caller must decrement the reference count by callingpci_dev_put().So before returning from amdgpu_device_resume|suspend_display_audio(),pci_dev_put() is called to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: efct: Fix possible memleak in efct_device_init()In efct_device_init(), when efct_scsi_reg_fc_transport() fails,efct_scsi_tgt_driver_exit() is not called to release memory forefct_scsi_tgt_driver_init() and causes memleak:unreferenced object 0xffff8881020ce000 (size 2048): comm "modprobe", pid 465, jiffies 4294928222 (age 55.872s) backtrace: [<0000000021a1ef1b>] kmalloc_trace+0x27/0x110 [<000000004c3ed51c>] target_register_template+0x4fd/0x7b0 [target_core_mod] [<00000000f3393296>] efct_scsi_tgt_driver_init+0x18/0x50 [efct] [<00000000115de533>] 0xffffffffc0d90011 [<00000000d608f646>] do_one_initcall+0xd0/0x4e0 [<0000000067828cf1>] do_init_module+0x1cc/0x6a0 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/lcs: Fix return type of lcs_start_xmit()With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed. Aproposed warning in clang aims to catch these at compile time, whichreveals: drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~ drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict] .ndo_start_xmit = lcs_start_xmit, ^~~~~~~~~~~~~~->ndo_start_xmit() in 'struct net_device_ops' expects a return type of'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() tomatch the prototype's to resolve the warning and potential CFI failure,should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: silence the warning when evicting inode with dioread_nolockWhen evicting an inode with default dioread_nolock, it could be raced bythe unwritten extents converting kworker after writeback some newallocated dirty blocks. It convert unwritten extents to written, theextents could be merged to upper level and free extent blocks, so itcould mark the inode dirty again even this inode has been markedI_FREEING. But the inode->i_io_list check and warning inext4_evict_inode() missing this corner case. Fortunately,ext4_evict_inode() will wait all extents converting finished before thischeck, so it will not lead to inode use-after-free problem, every thingis OK besides this warning. The WARN_ON_ONCE was originally designedfor finding inode use-after-free issues in advance, but if we addcurrent dioread_nolock case in, it will become not quite useful, so fixthis warning by just remove this check. ====== WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227 ext4_evict_inode+0x875/0xc60 ... RIP: 0010:ext4_evict_inode+0x875/0xc60 ... Call Trace: evict+0x11c/0x2b0 iput+0x236/0x3a0 do_unlinkat+0x1b4/0x490 __x64_sys_unlinkat+0x4c/0xb0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fa933c1115b ======rm kworker ext4_end_io_end()vfs_unlink() ext4_unlink() ext4_convert_unwritten_io_end_vec() ext4_convert_unwritten_extents() ext4_map_blocks() ext4_ext_map_blocks() ext4_ext_try_to_merge_up() __mark_inode_dirty() check !I_FREEING locked_inode_to_wb_and_lock_list() iput() iput_final() evict() ext4_evict_inode() truncate_inode_pages_final() //wait release io_end inode_io_list_move_locked() ext4_release_io_end() trigger WARN_ON_ONCE()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: akcipher - default implementation for setting a private keyChanges from v1: * removed the default implementation from set_pub_key: it is assumed that an implementation must always have this callback defined as there are no use case for an algorithm, which doesn't need a public keyMany akcipher implementations (like ECDSA) support only signatureverifications, so they don't have all callbacks defined.Commit 78a0324f4a53 ("crypto: akcipher - default implementations forrequest callbacks") introduced default callbacks for sign/verifyoperations, which just return an error code.However, these are not enough, because before calling sign the caller wouldlikely call set_priv_key first on the instantiated transform (as thein-kernel testmgr does). This function does not have a default stub, so thekernel crashes, when trying to set a private key on an akcipher, whichdoesn't support signature generation.I've noticed this, when trying to add a KAT vector for ECDSA signature tothe testmgr.With this patch the testmgr returns an error in dmesg (as it should)instead of crashing the kernel NULL ptr dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmem: core: Fix memleak in nvmem_register()dev_set_name will alloc memory for nvmem->dev.kobj.name innvmem_register, when nvmem_validate_keepouts failed, nvmem'smemory will be freed and return, but nobody will free memoryfor nvmem->dev.kobj.name, there will be memleak, so movingnvmem_validate_keepouts() after device_register() and letthe device core deal with cleaning name in error cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50741 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Disable useless interrupt to avoid kernel panicThere is a hardware bug that the interrupt STMBUF_HALF may be triggeredafter or when disable interrupt.It may led to unexpected kernel panic.And interrupt STMBUF_HALF and STMBUF_RTND have no other effect.So disable them and the unused interrupts.meanwhile clear the interrupt status when disable interrupt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set generation before calling btrfs_clean_tree_block in btrfs_init_new_buffersyzbot is reporting uninit-value in btrfs_clean_tree_block() [1], forcommit bc877d285ca3dba2 ("btrfs: Deduplicate extent_buffer init code")missed that btrfs_set_header_generation() in btrfs_init_new_buffer() mustnot be moved to after clean_tree_block() because clean_tree_block() iscalling btrfs_header_generation() since commit 55c69072d6bd5be1 ("Btrfs:Fix extent_buffer usage when nodesize != leafsize").Since memzero_extent_buffer() will reset "struct btrfs_header" part, wecan't move btrfs_set_header_generation() to before memzero_extent_buffer().Just re-add btrfs_set_header_generation() before btrfs_clean_tree_block().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()Running rcutorture with non-zero fqs_duration module parameter in akernel built with CONFIG_PREEMPTION=y results in the following splat:BUG: using __this_cpu_read() in preemptible [00000000]code: rcu_torture_fqs/398caller is __this_cpu_preempt_check+0x13/0x20CPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+Call Trace:dump_stack_lvl+0x5b/0x86dump_stack+0x10/0x16check_preemption_disabled+0xe5/0xf0__this_cpu_preempt_check+0x13/0x20rcu_force_quiescent_state.part.0+0x1c/0x170rcu_force_quiescent_state+0x1e/0x30rcu_torture_fqs+0xca/0x160? rcu_torture_boost+0x430/0x430kthread+0x192/0x1d0? kthread_complete_and_exit+0x30/0x30ret_from_fork+0x22/0x30The problem is that rcu_force_quiescent_state() uses __this_cpu_read()in preemptible code instead of the proper raw_cpu_read(). This committherefore changes __this_cpu_read() to raw_cpu_read().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50786 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: s5p-mfc: Clear workbit to handle error conditionDuring error on CLOSE_INSTANCE command, ctx_work_bits was not gettingcleared. During consequent mfc execution NULL pointer dereferencing ofthis context led to kernel panic. This patch fixes this issue by makingsure to clear ctx_work_bits always.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: devices: fix missing put_device in mport_cdev_openWhen kfifo_alloc fails, the refcount of chdev->dev is left incremental. We should use put_device(&chdev->dev) to decrease the ref count ofchdev->dev to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: fix missing unmap if z_erofs_get_extent_compressedlen() failsOtherwise, meta buffers could be leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: mcb: fix resource leak in mcb_probe()When probe hook function failed in mcb_probe(), it doesn't put the device.Compiled test only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/arm_dmc620: Fix hotplug callback leak in dmc620_pmu_init()dmc620_pmu_init() won't remove the callback added bycpuhp_setup_state_multi() when platform_driver_register() failed. Removethe callback by cpuhp_remove_multi_state() in fail path.Similar to the handling of arm_ccn_init() in commit 26242b330093 ("bus:arm-ccn: Prevent hotplug callback leak")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stream: purge sk_error_queue in sk_stream_kill_queues()Changheon Lee reported TCP socket leaks, with a nice repro.It seems we leak TCP sockets with the following sequence:1) SOF_TIMESTAMPING_TX_ACK is enabled on the socket. Each ACK will cook an skb put in error queue, from __skb_tstamp_tx(). __skb_tstamp_tx() is using skb_clone(), unless SOF_TIMESTAMPING_OPT_TSONLY was also requested.2) If the application is also using MSG_ZEROCOPY, then we put in the error queue cloned skbs that had a struct ubuf_info attached to them. Whenever an struct ubuf_info is allocated, sock_zerocopy_alloc() does a sock_hold(). As long as the cloned skbs are still in sk_error_queue, socket refcount is kept elevated.3) Application closes the socket, while error queue is not empty.Since tcp_close() no longer purges the socket error queue,we might end up with a TCP socket with at least one skb inerror queue keeping the socket alive forever.This bug can be (ab)used to consume all kernel memoryand freeze the host.We need to purge the error queue, with proper synchronizationagainst concurrent writers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: virtual_ncidev: Fix memory leak in virtual_nci_send()skb should be free in virtual_nci_send(), otherwise kmemleak will reportmemleak.Steps for reproduction (simulated in qemu): cd tools/testing/selftests/nci make ./nci_devBUG: memory leakunreferenced object 0xffff888107588000 (size 208): comm "nci_dev", pid 206, jiffies 4294945376 (age 368.248s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000008d94c8fd>] __alloc_skb+0x1da/0x290 [<00000000278bc7f8>] nci_send_cmd+0xa3/0x350 [<0000000081256a22>] nci_reset_req+0x6b/0xa0 [<000000009e721112>] __nci_request+0x90/0x250 [<000000005d556e59>] nci_dev_up+0x217/0x5b0 [<00000000e618ce62>] nfc_dev_up+0x114/0x220 [<00000000981e226b>] nfc_genl_dev_up+0x94/0xe0 [<000000009bb03517>] genl_family_rcv_msg_doit.isra.14+0x228/0x2d0 [<00000000b7f8c101>] genl_rcv_msg+0x35c/0x640 [<00000000c94075ff>] netlink_rcv_skb+0x11e/0x350 [<00000000440cfb1e>] genl_rcv+0x24/0x40 [<0000000062593b40>] netlink_unicast+0x43f/0x640 [<000000001d0b13cc>] netlink_sendmsg+0x73a/0xbf0 [<000000003272487f>] __sys_sendto+0x324/0x370 [<00000000ef9f1747>] __x64_sys_sendto+0xdd/0x1b0 [<000000001e437841>] do_syscall_64+0x3f/0x90

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: rio: fix possible name leak in rio_register_mport()If device_register() returns error, the name allocated by dev_set_name()need be freed. It should use put_device() to give up the reference in theerror path, so that the name can be freed in kobject_cleanup(), andlist_del() is called to delete the port from rio_mports.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: fix a signed-integer-overflow bug in tcp_add_backlog()The type of sk_rcvbuf and sk_sndbuf in struct sock is int, andin tcp_add_backlog(), the variable limit is caculated by addingsk_rcvbuf, sk_sndbuf and 64 * 1024, it may exceed the max valueof int and overflow. This patch reduces the limit budget byhalving the sndbuf to solve this issue since ACK packets are muchsmaller than the payload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Fix qmi_msg_handler data structure initializationqmi_msg_handler is required to be null terminated by QMI module.There might be a case where a handler for a msg id is not present in thehandlers array which can lead to infinite loop while searching the handlerand therefore out of bound access in qmi_invoke_handler().Hence update the initialization in qmi_msg_handler data structure.Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.5.0.1-01100-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 willbe NULL, and strcmp() will cause null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: broadcom: bcm4908_enet: update TX stats after actual transmissionQueueing packets doesn't guarantee their transmission. Update TX statsafter hardware confirms consuming submitted data.This also fixes a possible race and NULL dereference.bcm4908_enet_start_xmit() could try to access skb after freeing it inthe bcm4908_enet_poll_tx().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: qcom: q6v5: Fix potential null-ptr-deref in q6v5_wcss_init_mmio()q6v5_wcss_init_mmio() will call platform_get_resource_byname() that mayfail and return NULL. devm_ioremap() will use res->start as input, whichmay causes null-ptr-deref. Check the ret value ofplatform_get_resource_byname() to avoid the null-ptr-deref.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: Fix UAF in dm_integrity_dtr()Dm_integrity also has the same UAF problem when dm_resume()and dm_destroy() are concurrent.Therefore, cancelling timer again in dm_integrity_dtr().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52486 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: Don't unref the same fb many times by mistake due to deadlock handlingIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()we proceed to unref the fb and then retry the whole thing from the top.But we forget to reset the fb pointer back to NULL, and so if we thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it's still in use.Reset fb to NULL once we've unreffed it to avoid doing it againuntil we've done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52488 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn't increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52498 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Fix possible deadlocks in core system-wide PM codeIt is reported that in low-memory situations the system-wide resume corecode deadlocks, because async_schedule_dev() executes its argumentfunction synchronously if it cannot allocate memory (and not only inthat case) and that function attempts to acquire a mutex that is alreadyheld. Executing the argument function synchronously from withindpm_async_fn() may also be problematic for ordering reasons (it maycause a consumer device's resume callback to be invoked before arequisite supplier device's one, for example).Address this by changing the code in question to useasync_schedule_dev_nocall() for scheduling the asynchronousexecution of device suspend and resume functions and to directlyrun them synchronously if async_schedule_dev_nocall() returns false.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52522 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix possible store tearing in neigh_periodic_work()While looking at a related syzbot report involving neigh_periodic_work(),I found that I forgot to add an annotation when deleting anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52527 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()Including the transhdrlen in length is a problem when the packet ispartially filled (e.g. something like send(MSG_MORE) happened previously)when appending to an IPv4 or IPv6 packet as we don't want to repeat thetransport header or account for it twice. This can happen under somecircumstances, such as splicing into an L2TP socket.The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800that occurs when MSG_SPLICE_PAGES is used to append more data to an alreadypartially occupied skbuff. The warning occurs when 'copy' is larger thanthe amount of data in the message iterator. This is because the requestedlength includes the transport header length when it shouldn't. This can betriggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, ...); // ::1 connect(sfd, ...); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024);Fix this by only adding transhdrlen into the length if the write queue isempty in l2tp_ip6_sendmsg(), analogously to how UDP does things.l2tp_ip_sendmsg() looks like it won't suffer from this problem as it buildsthe UDP packet itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reservedAdding a reserved memory region for the framebuffer memory(the splash memory region set up by the bootloader).It fixes a kernel panic (arm-smmu: Unhandled context faultat this particular memory region) reported on DB845c runningv5.10.y.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52573 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rds: Fix possible NULL-pointer dereferenceIn rds_rdma_cm_event_handler_cmn() check, if conn pointer existsbefore dereferencing it as rdma_set_service_type() argumentFound by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52580 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/core: Fix ETH_P_1588 flow dissectorWhen a PTP ethernet raw frame with a size of more than 256 bytes followedby a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculationis wrong. For example: hdr->message_length takes the wrong value (0xffff)and it does not replicate real header length. In this case, 'nhoff' valuewas overridden and the PTP header was badly dissected. This leads to akernel crash.net/core: flow_dissectornet/core flow dissector nhoff = 0x0000000enet/core flow dissector hdr->message_length = 0x0000ffffnet/core flow dissector nhoff = 0x0001000d (u16 overflow)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffUsing the size of the ptp_header struct will allow the correctedcalculation of the nhoff value.net/core flow dissector nhoff = 0x0000000enet/core flow dissector nhoff = 0x00000030 (sizeof ptp_header)...skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ffskb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffskb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffKernel trace:[ 74.984279] ------------[ cut here ]------------[ 74.989471] kernel BUG at include/linux/skbuff.h:2440![ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI[ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1[ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023[ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130[ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9[ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297[ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003[ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300[ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800[ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010[ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800[ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000[ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0[ 75.121980] PKRU: 55555554[ 75.125035] Call Trace:[ 75.127792] [ 75.130063] ? eth_get_headlen+0xa4/0xc0[ 75.134472] igc_process_skb_fields+0xcd/0x150[ 75.139461] igc_poll+0xc80/0x17b0[ 75.143272] __napi_poll+0x27/0x170[ 75.147192] net_rx_action+0x234/0x280[ 75.151409] __do_softirq+0xef/0x2f4[ 75.155424] irq_exit_rcu+0xc7/0x110[ 75.159432] common_interrupt+0xb8/0xd0[ 75.163748] [ 75.166112] [ 75.168473] asm_common_interrupt+0x22/0x40[ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350[ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1[ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202[ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f[ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20[ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001[ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980[ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000[ 75.245635] ? ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak when more than 255 elements expiredWhen more than 255 elements expired we're supposed to switch to a new gccontainer structure.This never happens: u8 type will wrap before reaching the boundaryand nft_trans_gc_space() always returns true.This means we recycle the initial gc container structure andlose track of the elements that came before.While at it, don't deref 'gc' after we've passed it to call_rcu.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52598 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ptrace: handle setting of fpc register correctlyIf the content of the floating point control (fpc) register of a tracedprocess is modified with the ptrace interface the new value is tested forvalidity by temporarily loading it into the fpc register.This may lead to corruption of the fpc register of the tracing process:if an interrupt happens while the value is temporarily loaded into thefpc register, and within interrupt context floating point or vectorregisters are used, the current fp/vx registers are saved withsave_fpu_regs() assuming they belong to user space and will be loaded intofp/vx registers when returning to user space.test_fp_ctl() restores the original user space fpc register value, howeverit will be discarded, when returning to user space.In result the tracer will incorrectly continue to run with the value thatwas supposed to be used for the traced process.Fix this by saving fpu register contents with save_fpu_regs() before usingtest_fp_ctl().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/lib: Validate size for vector operationsSome of the fp/vmx code in sstep.c assume a certain maximum size for theinstructions being emulated. The size of those operations however isdetermined separately in analyse_instr().Add a check to validate the assumption on the maximum size of theoperations, so as to prevent any unintended kernel stack corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52608 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Check mailbox/SMT channel for consistencyOn reception of a completion interrupt the shared memory area is accessedto retrieve the message header at first and then, if the message sequencenumber identifies a transaction which is still pending, the relatedpayload is fetched too.When an SCMI command times out the channel ownership remains with theplatform until eventually a late reply is received and, as a consequence,any further transmission attempt remains pending, waiting for the channelto be relinquished by the platform.Once that late reply is received the channel ownership is given backto the agent and any pending request is then allowed to proceed andoverwrite the SMT area of the just delivered late reply; then the waitfor the reply to the new request starts.It has been observed that the spurious IRQ related to the late reply canbe wrongly associated with the freshly enqueued request: when that happensthe SCMI stack in-flight lookup procedure is fooled by the fact that themessage header now present in the SMT area is related to the new pendingtransaction, even though the real reply has still to arrive.This race-condition on the A2P channel can be detected by looking at thechannel status bits: a genuine reply from the platform will have set thechannel free bit before triggering the completion IRQ.Add a consistency check to validate such condition in the A2P ISR.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52610 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ct: fix skb leak and crash on ooo fragsact_ct adds skb->users before defragmentation. If frags arrive in order,the last frag's reference is reset in: inet_frag_reasm_prepare skb_morphwhich is not straightforward.However when frags arrive out of order, nobody unref the last frag, andall frags are leaked. The situation is even worse, as initiating packetcapture can lead to a crash[0] when skb has been cloned and shared at thesame time.Fix the issue by removing skb_get() before defragmentation. act_ctreturns TC_ACT_CONSUMED when defrag failed or in progress.[0]:[ 843.804823] ------------[ cut here ]------------[ 843.809659] kernel BUG at net/core/skbuff.c:2091![ 843.814516] invalid opcode: 0000 [#1] PREEMPT SMP[ 843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2[ 843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022[ 843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300[ 843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89[ 843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202[ 843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820[ 843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00[ 843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000[ 843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880[ 843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900[ 843.871680] FS: 0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000[ 843.876242] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0[ 843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 843.894229] PKRU: 55555554[ 843.898539] Call Trace:[ 843.902772] [ 843.906922] ? __die_body+0x1e/0x60[ 843.911032] ? die+0x3c/0x60[ 843.915037] ? do_trap+0xe2/0x110[ 843.918911] ? pskb_expand_head+0x2ac/0x300[ 843.922687] ? do_error_trap+0x65/0x80[ 843.926342] ? pskb_expand_head+0x2ac/0x300[ 843.929905] ? exc_invalid_op+0x50/0x60[ 843.933398] ? pskb_expand_head+0x2ac/0x300[ 843.936835] ? asm_exc_invalid_op+0x1a/0x20[ 843.940226] ? pskb_expand_head+0x2ac/0x300[ 843.943580] inet_frag_reasm_prepare+0xd1/0x240[ 843.946904] ip_defrag+0x5d4/0x870[ 843.950132] nf_ct_handle_fragments+0xec/0x130 [nf_conntrack][ 843.953334] tcf_ct_act+0x252/0xd90 [act_ct][ 843.956473] ? tcf_mirred_act+0x516/0x5a0 [act_mirred][ 843.959657] tcf_action_exec+0xa1/0x160[ 843.962823] fl_classify+0x1db/0x1f0 [cls_flower][ 843.966010] ? skb_clone+0x53/0xc0[ 843.969173] tcf_classify+0x24d/0x420[ 843.972333] tc_run+0x8f/0xf0[ 843.975465] __netif_receive_skb_core+0x67a/0x1080[ 843.978634] ? dev_gro_receive+0x249/0x730[ 843.981759] __netif_receive_skb_list_core+0x12d/0x260[ 843.984869] netif_receive_skb_list_internal+0x1cb/0x2f0[ 843.987957] ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core][ 843.991170] napi_complete_done+0x72/0x1a0[ 843.994305] mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core][ 843.997501] __napi_poll+0x25/0x1b0[ 844.000627] net_rx_action+0x256/0x330[ 844.003705] __do_softirq+0xb3/0x29b[ 844.006718] irq_exit_rcu+0x9e/0xc0[ 844.009672] common_interrupt+0x86/0xa0[ 844.012537] [ 844.015285] [ 844.017937] asm_common_interrupt+0x26/0x40[ 844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20[ 844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52623 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a suspicious RCU usage warningI received the following warning while running cthon against an ontapserver running pNFS:[ 57.202521] =============================[ 57.202522] WARNING: suspicious RCU usage[ 57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted[ 57.202525] -----------------------------[ 57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!![ 57.202527] other info that might help us debug this:[ 57.202528] rcu_scheduler_active = 2, debug_locks = 1[ 57.202529] no locks held by test5/3567.[ 57.202530] stack backtrace:[ 57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e[ 57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022[ 57.202536] Call Trace:[ 57.202537] [ 57.202540] dump_stack_lvl+0x77/0xb0[ 57.202551] lockdep_rcu_suspicious+0x154/0x1a0[ 57.202556] rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202596] rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202621] ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202646] rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202671] ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6][ 57.202696] nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202728] ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202754] nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202760] filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a][ 57.202765] pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202788] __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202813] nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202831] nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202849] nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202866] write_cache_pages+0x265/0x450[ 57.202870] ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202891] nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202913] do_writepages+0xd2/0x230[ 57.202917] ? filemap_fdatawrite_wbc+0x5c/0x80[ 57.202921] filemap_fdatawrite_wbc+0x67/0x80[ 57.202924] filemap_write_and_wait_range+0xd9/0x170[ 57.202930] nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902][ 57.202947] nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9][ 57.202969] __se_sys_close+0x46/0xd0[ 57.202972] do_syscall_64+0x68/0x100[ 57.202975] ? do_syscall_64+0x77/0x100[ 57.202976] ? do_syscall_64+0x77/0x100[ 57.202979] entry_SYSCALL_64_after_hwframe+0x6e/0x76[ 57.202982] RIP: 0033:0x7fe2b12e4a94[ 57.202985] Code: 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d d5 18 0e 00 00 74 13 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 44 c3 0f 1f 00 48 83 ec 18 89 7c 24 0c e8 c3[ 57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003[ 57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94[ 57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003[ 57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49[ 57.202993] R10: 00007f---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7091r: Allow users to configure device eventsAD7091R-5 devices are supported by the ad7091r-5 driver together withthe ad7091r-base driver. Those drivers declared iio events for notifyinguser space when ADC readings fall bellow the thresholds of low limitregisters or above the values set in high limit registers.However, to configure iio events and their thresholds, a set of callbackfunctions must be implemented and those were not present until now.The consequence of trying to configure ad7091r-5 events without theproper callback functions was a null pointer dereference in the kernelbecause the pointers to the callback functions were not set.Implement event configuration callbacks allowing users to read/writeevent thresholds and enable/disable event generation.Since the event spec structs are generic to AD7091R devices, also movethose from the ad7091r-5 driver the base driver so they can be reusedwhen support for ad7091r-2/-4/-8 be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52632 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix lock dependency warning with srcu======================================================WARNING: possible circular locking dependency detected6.5.0-kfd-yangp #2289 Not tainted------------------------------------------------------kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0-> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0-> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80-> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0other info that might help us debug this:Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work)Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52638 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: prevent deadlock by changing j1939_socks_lock to rwlockThe following 3 locks would race against each other, causing thedeadlock situation in the Syzbot bug report:- j1939_socks_lock- active_session_list_lock- sk_session_queue_lockA reasonable fix is to change j1939_socks_lock to an rwlock, since inthe rare situations where a write lock is required for the linked listthat j1939_socks_lock is protecting, the code does not attempt toacquire any more locks. This would break the circular lock dependency,where, for example, the current thread already locks j1939_socks_lockand attempts to acquire sk_session_queue_lock, and at the same time,another thread attempts to acquire j1939_socks_lock while holdingsk_session_queue_lock.NOTE: This patch along does not fix the unregister_netdevice bugreported by Syzbot; instead, it solves a deadlock situation to preparefor one or more further patches to actually fix the Syzbot bug, whichappears to be a reference counting problem within the j1939 codebase.[mkl: remove unrelated newline change]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52642 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rc: bpf attach/detach requires write permissionNote that bpf attach/detach also requires CAP_NET_ADMIN.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabledWhen QoS is disabled, the queue priority value will not map to the correctieee80211 queue since there is only one queue. Stop/wake queue 0 when QoSis disabled to prevent trying to stop/wake a non-existent queue and failingto stop/wake the actual queue instantiated.Log of issue before change (with kernel parameter qos=0): [ +5.112651] ------------[ cut here ]------------ [ +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000067] Modules linked in: b43(O) snd_seq_dummy snd_hrtimer snd_seq snd_seq_device nft_chain_nat xt_MASQUERADE nf_nat xfrm_user xfrm_algo xt_addrtype overlay ccm af_packet amdgpu snd_hda_codec_cirrus snd_hda_codec_generic ledtrig_audio drm_exec amdxcp gpu_sched xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6t_rpfilter ipt_rpfilter xt_pkttype xt_LOG nf_log_syslog xt_tcpudp nft_compat nf_tables nfnetlink sch_fq_codel btusb uinput iTCO_wdt ctr btrtl intel_pmc_bxt i915 intel_rapl_msr mei_hdcp mei_pxp joydev at24 watchdog btintel atkbd libps2 serio radeon btbcm vivaldi_fmap btmtk intel_rapl_common snd_hda_codec_hdmi bluetooth uvcvideo nls_iso8859_1 applesmc nls_cp437 x86_pkg_temp_thermal snd_hda_intel intel_powerclamp vfat videobuf2_vmalloc coretemp fat snd_intel_dspcfg crc32_pclmul uvc polyval_clmulni snd_intel_sdw_acpi loop videobuf2_memops snd_hda_codec tun drm_suballoc_helper polyval_generic drm_ttm_helper drm_buddy tap ecdh_generic videobuf2_v4l2 gf128mul macvlan ttm ghash_clmulni_intel ecc tg3 [ +0.000044] videodev bridge snd_hda_core rapl crc16 drm_display_helper cec mousedev snd_hwdep evdev intel_cstate bcm5974 hid_appleir videobuf2_common stp mac_hid libphy snd_pcm drm_kms_helper acpi_als mei_me intel_uncore llc mc snd_timer intel_gtt industrialio_triggered_buffer apple_mfi_fastcharge i2c_i801 mei snd lpc_ich agpgart ptp i2c_smbus thunderbolt apple_gmux i2c_algo_bit kfifo_buf video industrialio soundcore pps_core wmi tiny_power_button sbs sbshc button ac cordic bcma mac80211 cfg80211 ssb rfkill libarc4 kvm_intel kvm drm irqbypass fuse backlight firmware_class efi_pstore configfs efivarfs dmi_sysfs ip_tables x_tables autofs4 dm_crypt cbc encrypted_keys trusted asn1_encoder tee tpm rng_core input_leds hid_apple led_class hid_generic usbhid hid sd_mod t10_pi crc64_rocksoft crc64 crc_t10dif crct10dif_generic ahci libahci libata uhci_hcd ehci_pci ehci_hcd crct10dif_pclmul crct10dif_common sha512_ssse3 sha512_generic sha256_ssse3 sha1_ssse3 aesni_intel usbcore scsi_mod libaes crypto_simd cryptd scsi_common [ +0.000055] usb_common rtc_cmos btrfs blake2b_generic libcrc32c crc32c_generic crc32c_intel xor raid6_pq dm_snapshot dm_bufio dm_mod dax [last unloaded: b43(O)] [ +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G W O 6.6.7 #1-NixOS [ +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019 [ +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211] [ +0.000046] Code: 00 45 85 e4 0f 85 9b 00 00 00 48 8d bd 40 09 00 00 f0 48 0f ba ad 48 09 00 00 00 72 0f 5b 5d 41 5c 41 5d 41 5e e9 cb 6d 3c d0 <0f> 0b 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d b4 16 94 00 00 [ +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097 [ +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000 [ +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900 [ +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0 [ +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000 [ +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40 [ +0.000001] FS: 0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000 [ +0.000001] CS: 0010 DS: 0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: mediatek: fix race conditions with genpdIf the power domains are registered first with genpd and *after that*the driver attempts to power them on in the probe sequence, then it ispossible that a race condition occurs if genpd tries to power them onin the same time.The same is valid for powering them off before unregistering themfrom genpd.Attempt to fix race conditions by first removing the domains from genpdand *after that* powering down domains.Also first power up the domains and *after that* register themto genpd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aio: fix mremap after fork null-derefCommit e4a0d3e720e7 ("aio: Make it possible to remap aio ring") introduceda null-deref if mremap is called on an old aio mapping after fork asmm->ioctx_table will be set to NULL.[jmoyer@redhat.com: fix 80 column issue]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: eliminate double free in error handling logicDriver has a logic leak in ring data allocation/free,where aq_ring_free could be called multiple times on same ring,if system is under stress and got memory allocation error.Ring pointer was used as an indicator of failure, but this isnot correct since only ring data is allocated/deallocated.Ring itself is an array member.Changing ring allocation functions to return error code directly.This simplifies error handling and eliminates aq_ring_freeon higher layer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: s390/aes - Fix buffer overread in CTR modeWhen processing the last block, the s390 ctr code will always reada whole block, even if there isn't a whole block of data left. Fixthis by using the actual length left and copy it into a buffer firstfor processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52672 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pipe: wakeup wr_wait after setting max_usageCommit c73be61cede5 ("pipe: Add general notification queue support") aregression was introduced that would lock up resized pipes under certainconditions. See the reproducer in [1].The commit resizing the pipe ring size was moved to a differentfunction, doing that moved the wakeup for pipe->wr_wait before actuallyraising pipe->max_usage. If a pipe was full before the resize occured itwould result in the wakeup never actually triggering pipe_write.Set @max_usage and @nr_accounted before waking writers if this isn't awatch queue.[Christian Brauner : rewrite to account for watch queues]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52674 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 andSCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outsidescarlett2_mixer_values[].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: Fix double free in of_parse_phandle_with_args_mapIn of_parse_phandle_with_args_map() the inner loop thatiterates through the map entries calls of_node_put(new)to free the reference acquired by the previous iterationof the inner loop. This assumes that the value of "new" isNULL on the first iteration of the inner loop.Make sure that this is true in all iterations of the outerloop by setting "new" to NULL after its value is assigned to "cur".Extend the unittest to detect the double free and add an additionaltest case that actually triggers this path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error checks to *_ctl_get()The *_ctl_get() functions which call scarlett2_update_*() were notchecking the return value. Fix to check the return value and pass tothe caller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52683 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: LPIT: Avoid u32 multiplication overflowIn lpit_update_residency() there is a possibility of overflowin multiplication, if tsc_khz is large enough (> UINT_MAX/1000).Change multiplication to mul_u32_u32().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52685 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix a double-free in si_dpm_initWhen the allocation ofadev->pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,amdgpu_free_extended_power_table is called to free some fields of adev.However, when the control flow returns to si_dpm_sw_init, it goes tolabel dpm_failed and calls si_dpm_fini, which callsamdgpu_free_extended_power_table again and free those fields again. Thusa double-free is triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()scarlett2_usb_set_config() calls scarlett2_usb_get() but was notchecking the result. Return the error if it fails rather thancontinuing with an invalid value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe parent pci device.Check acpi_get_parent() result and set parent device only in case of success.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52694 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: tpd12s015: Drop buggy __exit annotation for remove functionWith tpd12s015_remove() marked with __exit this function is discardedwhen the driver is compiled as a built-in. The result is that when thedriver unbinds there is no cleanup done which results in resourceleakage or worse.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes. Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock access when mounting devices smaller than 4096 bytes: I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)In addition, when trying to resize the filesystem to a size below 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks. This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds. Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:segctord state:D stack:23456 pid:5067 ppid:2 flags:0x00004000 Call Trace: context_switch kernel/sched/core.c:5293 [inline] __schedule+0x1409/0x43f0 kernel/sched/core.c:6606 schedule+0xc3/0x190 kernel/sched/core.c:6682 rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190 nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357 nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline] nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570 kthread+0x270/0x300 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308 ... Call Trace: folio_mark_accessed+0x51c/0xf00 mm/swap.c:515 __nilfs_get_page_block fs/nilfs2/page.c:42 [inline] nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61 nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121 nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176 nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251 nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline] nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline] nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777 nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422 nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline] nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301 ...This fixes these issues by inserting appropriate minimum device sizechecks or anti-underflow checks, depending on where the macro is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itselfsock_map proto callbacks should never call themselves by design. Protectagainst bugs like [1] and break out of the recursive loop to avoid a stackoverflow in favor of a resource leak.[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM's integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit: 34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD being detected and enabled, e.g.| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : __pi_strcmp+0x1c/0x150| lr : populate_properties+0xe4/0x254| sp : ffffd014173d3ad0| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8| Kernel panic - not syncing: Unhandled exception| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1| Hardware name: linux,dummy-virt (DT)| Call trace:| dump_backtrace+0xec/0x108| show_stack+0x18/0x2c| dump_stack_lvl+0x50/0x68| dump_stack+0x18/0x24| panic+0x13c/0x340| el1t_64_irq_handler+0x0/0x1c| el1_abort+0x0/0x5c| el1h_64_sync+0x64/0x68| __pi_strcmp+0x1c/0x150| unflatten_dt_nodes+0x1e8/0x2d8| __unflatten_device_tree+0x5c/0x15c| unflatten_device_tree+0x38/0x50| setup_arch+0x164/0x1e0| start_kernel+0x64/0x38c| __primary_switched+0xbc/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM's IAS 15.0.0 and newer, which contains the linkedcommit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in smb2_query_info_compound()The following UAF was triggered when running fstests generic/072 withKASAN enabled against Windows Server 2022 and mount options'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm' BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs] Read of size 8 at addr ffff888014941048 by task xfs_io/27534 CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 Call Trace: dump_stack_lvl+0x4a/0x80 print_report+0xcf/0x650 ? srso_alias_return_thunk+0x5/0x7f ? srso_alias_return_thunk+0x5/0x7f ? __phys_addr+0x46/0x90 kasan_report+0xda/0x110 ? smb2_query_info_compound+0x423/0x6d0 [cifs] ? smb2_query_info_compound+0x423/0x6d0 [cifs] smb2_query_info_compound+0x423/0x6d0 [cifs] ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __stack_depot_save+0x39/0x480 ? kasan_save_stack+0x33/0x60 ? kasan_set_track+0x25/0x30 ? ____kasan_slab_free+0x126/0x170 smb2_queryfs+0xc2/0x2c0 [cifs] ? __pfx_smb2_queryfs+0x10/0x10 [cifs] ? __pfx___lock_acquire+0x10/0x10 smb311_queryfs+0x210/0x220 [cifs] ? __pfx_smb311_queryfs+0x10/0x10 [cifs] ? srso_alias_return_thunk+0x5/0x7f ? __lock_acquire+0x480/0x26c0 ? lock_release+0x1ed/0x640 ? srso_alias_return_thunk+0x5/0x7f ? do_raw_spin_unlock+0x9b/0x100 cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 ? __pfx___do_sys_fstatfs+0x10/0x10 ? srso_alias_return_thunk+0x5/0x7f ? lockdep_hardirqs_on_prepare+0x136/0x200 ? srso_alias_return_thunk+0x5/0x7f do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Allocated by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 open_cached_dir+0x71b/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs] smb311_queryfs+0x210/0x220 [cifs] cifs_statfs+0x18c/0x4b0 [cifs] statfs_by_dentry+0x9b/0xf0 fd_statfs+0x4e/0xb0 __do_sys_fstatfs+0x7f/0xe0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 Freed by task 27534: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 ____kasan_slab_free+0x126/0x170 slab_free_freelist_hook+0xd0/0x1e0 __kmem_cache_free+0x9d/0x1b0 open_cached_dir+0xff5/0x1240 [cifs] smb2_query_info_compound+0x5c3/0x6d0 [cifs] smb2_queryfs+0xc2/0x2c0 [cifs]This is a race between open_cached_dir() and cached_dir_lease_break()where the cache entry for the open directory handle receives a leasebreak while creating it. And before returning from open_cached_dir(),we put the last reference of the new @cfid because of!@cfid->has_lease.Besides the UAF, while running xfstests a lot of missed lease breakshave been noticed in tests that run several concurrent statfs(2) callson those cached fids CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108 CIFS: VFS: Dump pending requests: CIFS: VFS: \\w22-root1.gandalf.test No task to wake, unknown frame... CIFS: VFS: \\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1... CIFS: VFS: \\w22-root1.gandalf.test smb buf 000000005aa7316e len 108 ...To fix both, in open_cached_dir() ensure that @cfid->has_lease is setright before sending out compounded request so that any potentiallease break will be get processed by demultiplex thread while we'restill caching @cfid. And, if open failed for some reason, re-check@cfid->has_lease to decide whether or not put lease reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: add ipvlan_route_v6_outbound() helperInspired by syzbot reports using a stack of multiple ipvlan devices.Reduce stack size needed in ipvlan_process_v6_outbound() by movingthe flowi6 struct used for the route lookup in an non inlinedhelper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,immediately reclaimed.Also make sure ipvlan_process_v4_outbound() is not inlined.We might also have to lower MAX_NEST_DEV, because only syzbot usessetups with more than four stacked devices.BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)stack guard page: 0000 [#1] SMP KASANCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188Code: 48 01 c6 48 89 c7 e8 db 4e c1 03 31 c0 5d c3 cc 0f 0b eb 02 0f 0b b8 ea ff ff ff 5d c3 cc 00 00 cc cc 00 00 cc cc 55 48 89 e5 <41> 57 41 56 41 55 41 54 53 b0 01 48 85 f6 0f 84 a4 01 00 00 48 89RSP: 0018:ffffc9000e804000 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080cR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:<#DF>[] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31[] instrument_atomic_read include/linux/instrumented.h:72 [inline][] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline][] cpumask_test_cpu include/linux/cpumask.h:506 [inline][] cpu_online include/linux/cpumask.h:1092 [inline][] trace_lock_acquire include/trace/events/lock.h:24 [inline][] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632[] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306[] rcu_read_lock include/linux/rcupdate.h:747 [inline][] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221[] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606[] pol_lookup_func include/net/ip6_fib.h:584 [inline][] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116[] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638[] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651[] ip6_route_output include/net/ip6_route.h:100 [inline][] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4966 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324[] dev_queue_xmit include/linux/netdevice.h:3067 [inline][] neigh_hh_output include/net/neighbour.h:529 [inline][

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfsIf init debugfs failed during device registration due to memory allocationfailure, debugfs_remove_recursive() is called, after which debugfs_dir isnot set to NULL. debugfs_remove_recursive() will be called again duringdevice removal. As a result, illegal pointer is accessed.[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!...[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[ 1669.872669] pc : down_write+0x24/0x70[ 1669.876315] lr : down_write+0x1c/0x70[ 1669.879961] sp : ffff000036f53a30[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001[ 1669.962563] Call trace:[ 1669.965000] down_write+0x24/0x70[ 1669.968301] debugfs_remove_recursive+0x5c/0x1b0[ 1669.972905] hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main][ 1669.978541] hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw][ 1669.984175] pci_device_remove+0x48/0xd8[ 1669.988082] device_release_driver_internal+0x1b4/0x250[ 1669.993282] device_release_driver+0x28/0x38[ 1669.997534] pci_stop_bus_device+0x84/0xb8[ 1670.001611] pci_stop_and_remove_bus_device_locked+0x24/0x40[ 1670.007244] remove_store+0xfc/0x140[ 1670.010802] dev_attr_store+0x44/0x60[ 1670.014448] sysfs_kf_write+0x58/0x80[ 1670.018095] kernfs_fop_write+0xe8/0x1f0[ 1670.022000] __vfs_write+0x60/0x190[ 1670.025472] vfs_write+0xac/0x1c0[ 1670.028771] ksys_write+0x6c/0xd8[ 1670.032071] __arm64_sys_write+0x24/0x30[ 1670.035977] el0_svc_common+0x78/0x130[ 1670.039710] el0_svc_handler+0x38/0x78[ 1670.043442] el0_svc+0x8/0xcTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds."echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst->flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon't call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&wait->completion), which will causehungtask.The problem comes as following:(padata_do_parallel) | rcu_read_lock_bh(); | err = -EINVAL; | (padata_replace) | pinst->flags |= PADATA_RESET; err = -EBUSY | if (pinst->flags & PADATA_RESET) | rcu_read_unlock_bh() | return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: verify mac len before reading mac headerLLC reads the mac header with eth_hdr without verifying that the skbhas an Ethernet header.Syzbot was able to enter llc_rcv on a tun device. Tun can insertpackets without mac len and with user configurable skb->protocol(passing a tun_pi header when not configuring IFF_NO_PI). BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline] llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111 llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555 tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002Add a mac_len test before all three eth_hdr(skb) calls under net/llc.There are further uses in include/net/llc_pdu.h. All these areprotected by a test skb->protocol == ETH_P_802_2. Which does notprotect against this tun scenario.But the mac_len test added in this patch in llc_fixup_skb willindirectly protect those too. That is called from llc_rcv before anyother LLC code.It is tempting to just add a blanket mac_len check in llc_rcv, butnot sure whether that could break valid LLC paths that do not assumean Ethernet header. 802.2 LLC may be used on top of non-802.3protocols in principle. The below referenced commit shows that usedto, on top of Token Ring.At least one of the three eth_hdr uses goes back to before the startof git history. But the one that syzbot exercises is introduced inthis commit. That commit is old enough (2008), that effectively allstable kernels should receive this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Change nla_policy for bearer-related names to NLA_NUL_STRINGsyzbot reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756 strlen lib/string.c:418 [inline] strstr+0xb8/0x2f0 lib/string.c:756 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline] genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline] netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885 sock_sendmsg_nosec net/socket.c:730 [inline] sock_sendmsg net/socket.c:753 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595 __sys_sendmsg net/socket.c:2624 [inline] __do_sys_sendmsg net/socket.c:2633 [inline] __se_sys_sendmsg net/socket.c:2631 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdTIPC bearer-related names including link names must be null-terminatedstrings. If a link name which is not null-terminated is passed throughnetlink, strstr() and similar functions can cause buffer overrun. Thiscauses the above issue.This patch changes the nla_policy for bearer-related names from NLA_STRINGto NLA_NUL_STRING. This resolves the issue by ensuring that onlynull-terminated strings are accepted as bearer-related names.syzbot reported similar uninit-value issue related to bearer names [2]. Theroot cause of this issue is that a non-null-terminated bearer name waspassed. This patch also resolved this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (axi-fan-control) Fix possible NULL pointer dereferenceaxi_fan_control_irq_handler(), dependent on the privateaxi_fan_control_data structure, might be called before the hwmondevice is registered. That will cause an "Unable to handle kernelNULL pointer dereference" error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix null pointer deref when receiving skb during sock creationThe panic below is observed when receiving ICMP packets with secmark setwhile an ICMP raw socket is being created. SK_CTX(sk)->label is updatedin apparmor_socket_post_create(), but the packet is delivered to thesocket before that, causing the null pointer dereference.Drop the packet if label context is not set. BUG: kernel NULL pointer dereference, address: 000000000000004c #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020 RIP: 0010:aa_label_next_confined+0xb/0x40 Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 <8b> 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2 RSP: 0018:ffffa92940003b08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002 R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400 R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000 FS: 00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0 PKRU: 55555554 Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x171/0x4e0 ? exc_page_fault+0x7f/0x180 ? asm_exc_page_fault+0x26/0x30 ? aa_label_next_confined+0xb/0x40 apparmor_secmark_check+0xec/0x330 security_sock_rcv_skb+0x35/0x50 sk_filter_trim_cap+0x47/0x250 sock_queue_rcv_skb_reason+0x20/0x60 raw_rcv+0x13c/0x210 raw_local_deliver+0x1f3/0x250 ip_protocol_deliver_rcu+0x4f/0x2f0 ip_local_deliver_finish+0x76/0xa0 __netif_receive_skb_one_core+0x89/0xa0 netif_receive_skb+0x119/0x170 ? __netdev_alloc_skb+0x3d/0x140 vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a] __napi_poll+0x28/0x1b0 net_rx_action+0x2a4/0x380 __do_softirq+0xd1/0x2c8 __irq_exit_rcu+0xbb/0xf0 common_interrupt+0x86/0xa0 asm_common_interrupt+0x26/0x40 RIP: 0010:apparmor_socket_post_create+0xb/0x200 Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 <55> 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48 RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286 RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740 RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003 R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748 ? __pfx_apparmor_socket_post_create+0x10/0x10 security_socket_post_create+0x4b/0x80 __sock_create+0x176/0x1f0 __sys_socket+0x89/0x100 __x64_sys_socket+0x17/0x20 do_syscall_64+0x5d/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 ? do_syscall_64+0x6c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Add exception protection processing for vd in axi_chan_handle_err functionSince there is no protection for vd, a kernel panic will betriggered here in exceptional cases.You can refer to the processing of axi_chan_block_xfer_complete functionThe triggered kernel panic is as follows:[ 67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 67.848447] Mem abort info:[ 67.848449] ESR = 0x96000004[ 67.848451] EC = 0x25: DABT (current EL), IL = 32 bits[ 67.848454] SET = 0, FnV = 0[ 67.848456] EA = 0, S1PTW = 0[ 67.848458] Data abort info:[ 67.848460] ISV = 0, ISS = 0x00000004[ 67.848462] CM = 0, WnR = 0[ 67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000[ 67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000[ 67.848472] Internal error: Oops: 96000004 [#1] SMP[ 67.848475] Modules linked in: dmatest[ 67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11[ 67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)[ 67.848487] pc : axi_chan_handle_err+0xc4/0x230[ 67.848491] lr : axi_chan_handle_err+0x30/0x230[ 67.848493] sp : ffff0803fe55ae50[ 67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200[ 67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080[ 67.848504] x25: ffff800010d33880 x24: ffff80001139d850[ 67.848508] x23: ffff0800c097c168 x22: 0000000000000000[ 67.848512] x21: 0000000000000080 x20: 0000000000002000[ 67.848517] x19: ffff0800c097c080 x18: 0000000000000000[ 67.848521] x17: 0000000000000000 x16: 0000000000000000[ 67.848525] x15: 0000000000000000 x14: 0000000000000000[ 67.848529] x13: 0000000000000000 x12: 0000000000000040[ 67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a[ 67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270[ 67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0[ 67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480[ 67.848550] x3 : dead000000000100 x2 : dead000000000122[ 67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168[ 67.848559] Call trace:[ 67.848562] axi_chan_handle_err+0xc4/0x230[ 67.848566] dw_axi_dma_interrupt+0xf4/0x590[ 67.848569] __handle_irq_event_percpu+0x60/0x220[ 67.848573] handle_irq_event+0x64/0x120[ 67.848576] handle_fasteoi_irq+0xc4/0x220[ 67.848580] __handle_domain_irq+0x80/0xe0[ 67.848583] gic_handle_irq+0xc0/0x138[ 67.848585] el1_irq+0xc8/0x180[ 67.848588] arch_cpu_idle+0x14/0x2c[ 67.848591] default_idle_call+0x40/0x16c[ 67.848594] do_idle+0x1f0/0x250[ 67.848597] cpu_startup_entry+0x2c/0x60[ 67.848600] rest_init+0xc0/0xcc[ 67.848603] arch_call_rest_init+0x14/0x1c[ 67.848606] start_kernel+0x4cc/0x500[ 67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)[ 67.848613] ---[ end trace 585a97036f88203a ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52906 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mpls: Fix warning during failed attribute validationThe 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has avalidation type of 'NLA_VALIDATE_FUNCTION'. This is an invalidcombination according to the comment above 'struct nla_policy':"Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN: NLA_BINARY Validation function called for the attribute. All other Unused - but note that it's a union"This can trigger the warning [1] in nla_get_range_unsigned() whenvalidation of the attribute fails. Despite being of 'NLA_U32' type, theassociated 'min'/'max' fields in the policy are negative as they arealiased by the 'validate' field.Fix by changing the attribute type to 'NLA_BINARY' which is consistentwith the above comment and all other users of NLA_POLICY_VALIDATE_FN().As a result, move the length validation to the validation function.No regressions in MPLS tests: # ./tdc.py -f tc-tests/actions/mpls.json [...] # echo $? 0[1]WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117Modules linked in:CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117[...]Call Trace: __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline] netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0x38f/0x500 net/socket.c:2482 ___sys_sendmsg net/socket.c:2536 [inline] __sys_sendmsg+0x197/0x230 net/socket.c:2565 __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52916 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: aspeed: Fix memory overwrite if timing is 1600x900When capturing 1600x900, system could crash when system memory usage istight.The way to reproduce this issue:1. Use 1600x900 to display on host2. Mount ISO through 'Virtual media' on OpenBMC's web3. Run script as below on host to do sha continuously #!/bin/bash while [ [1] ]; do find /media -type f -printf '"%h/%f"\n' | xargs sha256sum done4. Open KVM on OpenBMC's webThe size of macro block captured is 8x8. Therefore, we should make surethe height of src-buf is 8 aligned to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52918 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: pci: cx23885: check cx23885_vdev_init() returncx23885_vdev_init() can return a NULL pointer, but that pointeris used in the next line without a check.Add a NULL pointer check and go to the error unwind if it is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: support non-r10 register spill/fill to/from stack in precision trackingUse instruction (jump) history to record instructions that performedregister spill/fill to/from stack, regardless if this was done throughread-only r10 register, or any other register after copying r10 into it*and* potentially adjusting offset.To make this work reliably, we push extra per-instruction flags intoinstruction history, encoding stack slot index (spi) and stack framenumber in extra 10 bit flags we take away from prev_idx in instructionhistory. We don't touch idx field for maximum performance, as it'schecked most frequently during backtracking.This change removes basically the last remaining practical limitation ofprecision backtracking logic in BPF verifier. It fixes knowndeficiencies, but also opens up new opportunities to reduce number ofverified states, explored in the subsequent patches.There are only three differences in selftests' BPF object filesaccording to veristat, all in the positive direction (less states).File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF)-------------------------------------- ------------- --------- --------- ------------- ---------- ---------- -------------test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%)xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%)xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%)Note, I avoided renaming jmp_history to more generic insn_hist tominimize number of lines changed and potential merge conflicts betweenbpf and bpf-next trees.Notice also cur_hist_entry pointer reset to NULL at the beginning ofinstruction verification loop. This pointer avoids the problem ofrelying on last jump history entry's insn_idx to determine whether wealready have entry for current instruction or not. It can happen that weadded jump history entry because current instruction is_jmp_point(), butalso we need to add instruction flags for stack access. In this case, wedon't want to entries, so we need to reuse last added entry, if it ispresent.Relying on insn_idx comparison has the same ambiguity problem as the onethat was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52936 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: kprobe: Fixup kernel panic when probing an illegal positionThe kernel would panic when probed for an illegal position. eg:(CONFIG_RISCV_ISA_C=n)echo 'p:hello kernel_clone+0x16 a0=%a0' >> kprobe_eventsecho 1 > events/kprobes/hello/enablecat traceKernel panic - not syncing: stack-protector: Kernel stackis corrupted in: __do_sys_newfstatat+0xb8/0xb8CPU: 0 PID: 111 Comm: sh Not tainted6.2.0-rc1-00027-g2d398fe49a4d #490Hardware name: riscv-virtio,qemu (DT)Call Trace:[] dump_backtrace+0x38/0x48[] show_stack+0x50/0x68[] dump_stack_lvl+0x60/0x84[] dump_stack+0x20/0x30[] panic+0x160/0x374[] generic_handle_arch_irq+0x0/0xa8[] sys_newstat+0x0/0x30[] sys_clone+0x20/0x30[] ret_from_syscall+0x0/0x4---[ end Kernel panic - not syncing: stack-protector:Kernel stack is corrupted in: __do_sys_newfstatat+0xb8/0xb8 ]---That is because the kprobe's ebreak instruction broke the kernel'soriginal code. The user should guarantee the correction of the probeposition, but it couldn't make the kernel panic.This patch adds arch_check_kprobe in arch_prepare_kprobe to prevent anillegal position (Such as the middle of an instruction).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix request ref counting during error capture & debugfs dumpWhen GuC support was added to error capture, the reference countingaround the request object was broken. Fix it up.The context based search manages the spinlocking around the searchinternally. So it needs to grab the reference count internally aswell. The execlist only request based search relies on externallocking, so it needs an external reference count but within thespinlock not outside it.The only other caller of the context based search is the code fordumping engine state to debugfs. That code wasn't previously gettingan explicit reference at all as it does everything while holding theexeclist specific spinlock. So, that needs updaing as well as thatspinlock doesn't help when using GuC submission. Rather than trying toconditionally get/put depending on submission model, just change it toalways do the get/put.v2: Explicitly document adding an extra blank line in some dense code(Andy Shevchenko). Fix multiple potential null pointer derefs in caseof no request found (some spotted by Tvrtko, but there was more!).Also fix a leaked request in case of !started and another in__guc_reset_context now that intel_context_find_active_request isactually reference counting the returned request.v3: Add a _get suffix to intel_context_find_active_request now that itgrabs a reference (Daniele).v4: Split the intel_guc_find_hung_context change to a separate patchand rename intel_context_find_active_request_get tointel_context_get_active_request (Tvrtko).v5: s/locking/reference counting/ in commit message (Tvrtko)(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Check for any of tcp_bpf_prots when cloning a listenerA listening socket linked to a sockmap has its sk_prot overridden. Itpoints to one of the struct proto variants in tcp_bpf_prots. The variantdepends on the socket's family and which sockmap programs are attached.A child socket cloned from a TCP listener initially inherits their sk_prot.But before cloning is finished, we restore the child's proto to thelistener's original non-tcp_bpf_prots one. This happens intcp_create_openreq_child -> tcp_bpf_clone.Today, in tcp_bpf_clone we detect if the child's proto should be restoredby checking only for the TCP_BPF_BASE proto variant. This is notcorrect. The sk_prot of listening socket linked to a sockmap can point toto any variant in tcp_bpf_prots.If the listeners sk_prot happens to be not the TCP_BPF_BASE variant, thenthe child socket unintentionally is left if the inherited sk_prot bytcp_bpf_clone.This leads to issues like infinite recursion on close [1], because thechild state is otherwise not set up for use with tcp_bpf_prot operations.Adjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.Note that it wouldn't be sufficient to check the socket state whenoverriding the sk_prot in tcp_bpf_update_proto in order to always use theTCP_BPF_BASE variant for listening sockets. Since commitb8b8315e39ff ("bpf, sockmap: Remove unhash handler for BPF sockmap usage")it is possible for a socket to transition to TCP_LISTEN state while alreadylinked to a sockmap, e.g. connect() -> insert into map ->connect(AF_UNSPEC) -> listen().[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer in skb_segment_listCommit 3a1296a38d0c ("net: Support GRO/GSO fraglist chaining.")introduced UDP listifyed GRO. The segmentation relies on frag_list beinguntouched when passing through the network stack. This assumption can bebroken sometimes, where frag_list itself gets pulled into linear area,leaving frag_list being NULL. When this happens it can triggerfollowing NULL pointer dereference, and panic the kernel. Reverse thetest condition should fix it.[19185.577801][ C1] BUG: kernel NULL pointer dereference, address:...[19185.663775][ C1] RIP: 0010:skb_segment_list+0x1cc/0x390...[19185.834644][ C1] Call Trace:[19185.841730][ C1] [19185.848563][ C1] __udp_gso_segment+0x33e/0x510[19185.857370][ C1] inet_gso_segment+0x15b/0x3e0[19185.866059][ C1] skb_mac_gso_segment+0x97/0x110[19185.874939][ C1] __skb_gso_segment+0xb2/0x160[19185.883646][ C1] udp_queue_rcv_skb+0xc3/0x1d0[19185.892319][ C1] udp_unicast_rcv_skb+0x75/0x90[19185.900979][ C1] ip_protocol_deliver_rcu+0xd2/0x200[19185.910003][ C1] ip_local_deliver_finish+0x44/0x60[19185.918757][ C1] __netif_receive_skb_one_core+0x8b/0xa0[19185.927834][ C1] process_backlog+0x88/0x130[19185.935840][ C1] __napi_poll+0x27/0x150[19185.943447][ C1] net_rx_action+0x27e/0x5f0[19185.951331][ C1] ? mlx5_cq_tasklet_cb+0x70/0x160 [mlx5_core][19185.960848][ C1] __do_softirq+0xbc/0x25d[19185.968607][ C1] irq_exit_rcu+0x83/0xb0[19185.976247][ C1] common_interrupt+0x43/0xa0[19185.984235][ C1] asm_common_interrupt+0x22/0x40...[19186.094106][ C1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: Fix suspend with Xen PVCommit f1e525009493 ("x86/boot: Skip realmode init code when running asXen PV guest") missed one code path accessing real_mode_header, leadingto dereferencing NULL when suspending the system under Xen: [ 348.284004] PM: suspend entry (deep) [ 348.289532] Filesystems sync: 0.005 seconds [ 348.291545] Freezing user space processes ... (elapsed 0.000 seconds) done. [ 348.292457] OOM killer disabled. [ 348.292462] Freezing remaining freezable tasks ... (elapsed 0.104 seconds) done. [ 348.396612] printk: Suspending console(s) (use no_console_suspend to debug) [ 348.749228] PM: suspend devices took 0.352 seconds [ 348.769713] ACPI: EC: interrupt blocked [ 348.816077] BUG: kernel NULL pointer dereference, address: 000000000000001c [ 348.816080] #PF: supervisor read access in kernel mode [ 348.816081] #PF: error_code(0x0000) - not-present page [ 348.816083] PGD 0 P4D 0 [ 348.816086] Oops: 0000 [#1] PREEMPT SMP NOPTI [ 348.816089] CPU: 0 PID: 6764 Comm: systemd-sleep Not tainted 6.1.3-1.fc32.qubes.x86_64 #1 [ 348.816092] Hardware name: Star Labs StarBook/StarBook, BIOS 8.01 07/03/2022 [ 348.816093] RIP: e030:acpi_get_wakeup_address+0xc/0x20Fix that by adding an optional acpi callback allowing to skip settingthe wakeup address, as in the Xen PV case this will be handled by thehypervisor anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv/kprobe: Fix instruction simulation of JALRSet kprobe at 'jalr 1140(ra)' of vfs_write results in the followingcrash:[ 32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170[ 32.093115] Oops [#1][ 32.093251] Modules linked in:[ 32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16[ 32.093985] Hardware name: riscv-virtio,qemu (DT)[ 32.094280] epc : ksys_read+0x88/0xd6[ 32.094855] ra : ksys_read+0xc0/0xd6[ 32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0[ 32.095227] gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80[ 32.095500] t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60[ 32.095716] s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708[ 32.095921] a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300[ 32.096171] a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff[ 32.096411] s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170[ 32.096638] s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030[ 32.096865] s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410[ 32.097092] s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c[ 32.097317] t5 : ffffffff8000c29c t6 : ffffffff800dbc54[ 32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d[ 32.098011] [] ksys_write+0x6c/0xd6[ 32.098222] [] sys_write+0x2a/0x38[ 32.098405] [] ret_from_syscall+0x0/0x2Since the rs1 and rd might be the same one, such as 'jalr 1140(ra)',hence it requires obtaining the target address from rs1 followed byupdating rd.[Palmer: Pick Guo's cleanup]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in fib_metrics_match()if (!type) continue; if (type > RTAX_MAX) return false; ... fi_val = fi->fib_metrics->metrics[type - 1];@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: prevent potential spectre v1 gadget in ip_metrics_convert()if (!type) continue; if (type > RTAX_MAX) return -EINVAL; ... metrics[type - 1] = val;@type being used as an array index, we need to preventcpu speculation or risk leaking kernel memory content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Fix a memory leak with reused mmap_offsetdrm_vma_node_allow() and drm_vma_node_revoke() should be called inbalanced pairs. We call drm_vma_node_allow() once per-file everytime auser calls mmap_offset, but only call drm_vma_node_revoke once per-fileon each mmap_offset. As the mmap_offset is reused by the client, theper-file vm_count may remain non-zero and the rbtree leaked.Call drm_vma_node_allow_once() instead to prevent that memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/qcom: Do not pass llcc_driv_data as edac_device_ctl_info's pvt_infoThe memory for llcc_driv_data is allocated by the LLCC driver. But whenit is passed as the private driver info to the EDAC core, it will get freedduring the qcom_edac driver release. So when the qcom_edac driver gets probedagain, it will try to use the freed data leading to the use-after-free bug.Hence, do not pass llcc_driv_data as pvt_info but rather reference itusing the platform_data pointer in the qcom_edac driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add sync after creating vram boThere will be data corruption on vram allocated by svmif the initialization is not complete and application iswritting on the memory. Adding sync to wait for theinitialization completion is to resolve this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: enable all safety features by defaultIn the original implementation of dwmac5commit 8bf993a5877e ("net: stmmac: Add support for DWMAC5 and implement Safety Features")all safety features were enabled by default.Later it seems some implementations didn't have support for all thefeatures, so incommit 5ac712dcdfef ("net: stmmac: enable platform specific safety features")the safety_feat_cfg structure was added to the callback and defined forsome platforms to selectively enable these safety features.The problem is that only certain platforms were given that softwaresupport. If the automotive safety package bit is set in the hardwarefeatures register the safety feature callback is called for the platform,and for platforms that didn't get a safety_feat_cfg defined this resultsin the following NULL pointer dereference:[ 7.933303] Call trace:[ 7.935812] dwmac5_safety_feat_config+0x20/0x170 [stmmac][ 7.941455] __stmmac_open+0x16c/0x474 [stmmac][ 7.946117] stmmac_open+0x38/0x70 [stmmac][ 7.950414] __dev_open+0x100/0x1dc[ 7.954006] __dev_change_flags+0x18c/0x204[ 7.958297] dev_change_flags+0x24/0x6c[ 7.962237] do_setlink+0x2b8/0xfa4[ 7.965827] __rtnl_newlink+0x4ec/0x840[ 7.969766] rtnl_newlink+0x50/0x80[ 7.973353] rtnetlink_rcv_msg+0x12c/0x374[ 7.977557] netlink_rcv_skb+0x5c/0x130[ 7.981500] rtnetlink_rcv+0x18/0x2c[ 7.985172] netlink_unicast+0x2e8/0x340[ 7.989197] netlink_sendmsg+0x1a8/0x420[ 7.993222] ____sys_sendmsg+0x218/0x280[ 7.997249] ___sys_sendmsg+0xac/0x100[ 8.001103] __sys_sendmsg+0x84/0xe0[ 8.004776] __arm64_sys_sendmsg+0x24/0x30[ 8.008983] invoke_syscall+0x48/0x114[ 8.012840] el0_svc_common.constprop.0+0xcc/0xec[ 8.017665] do_el0_svc+0x38/0xb0[ 8.021071] el0_svc+0x2c/0x84[ 8.024212] el0t_64_sync_handler+0xf4/0x120[ 8.028598] el0t_64_sync+0x190/0x194Go back to the original behavior, if the automotive safety packageis found to be supported in hardware enable all the features unlesssafety_feat_cfg is passed in saying this particular platform onlysupports a subset of the features.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53012 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: call put_device() only after device_register() failsput_device() shouldn't be called before a prior call todevice_register(). __thermal_cooling_device_register() doesn't followthat properly and needs fixing. Alsothermal_cooling_device_destroy_sysfs() is getting called unnecessarilyon few error paths.Fix all this by placing the calls at the right place.Based on initial work done by Caleb Connolly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptdma: pt_core_execute_cmd() should use spinlockThe interrupt handler (pt_core_irq_handler()) of the ptdmadriver can be called from interrupt context. The code flowin this function can lead down to pt_core_execute_cmd() whichwill attempt to grab a mutex, which is not appropriate ininterrupt context and ultimately leads to a kernel panic.The fix here changes this mutex to a spinlock, which hasbeen verified to resolve the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:l2tp: close all race conditions in l2tp_tunnel_register()The code in l2tp_tunnel_register() is racy in several ways:1. It modifies the tunnel socket _after_ publishing it.2. It calls setup_udp_tunnel_sock() on an existing socket without locking.3. It changes sock lock class on fly, which triggers many syzbot reports.This patch amends all of them by moving socket initialization codebefore publishing and under sock lock. As suggested by Jakub, thel2tp lockdep class is not necessary as we can just switch tobh_lock_sock_nested().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53021 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_taprio: fix possible use-after-freesyzbot reported a nasty crash [1] in net_tx_action() whichmade little sense until we got a repro.This repro installs a taprio qdisc, but providing aninvalid TCA_RATE attribute.qdisc_create() has to destroy the just initializedtaprio qdisc, and taprio_destroy() is called.However, the hrtimer used by taprio had already fired,therefore advance_sched() called __netif_schedule().Then net_tx_action was trying to use a destroyed qdisc.We can not undo the __netif_schedule(), so we must waituntil one cpu serviced the qdisc before we can proceed.Many thanks to Alexander Potapenko for his help.[1]BUG: KMSAN: uninit-value in queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline]BUG: KMSAN: uninit-value in do_raw_spin_trylock include/linux/spinlock.h:191 [inline]BUG: KMSAN: uninit-value in __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline]BUG: KMSAN: uninit-value in _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 queued_spin_trylock include/asm-generic/qspinlock.h:94 [inline] do_raw_spin_trylock include/linux/spinlock.h:191 [inline] __raw_spin_trylock include/linux/spinlock_api_smp.h:89 [inline] _raw_spin_trylock+0x92/0xa0 kernel/locking/spinlock.c:138 spin_trylock include/linux/spinlock.h:359 [inline] qdisc_run_begin include/net/sch_generic.h:187 [inline] qdisc_run+0xee/0x540 include/net/pkt_sched.h:125 net_tx_action+0x77c/0x9a0 net/core/dev.c:5086 __do_softirq+0x1cc/0x7fb kernel/softirq.c:571 run_ksoftirqd+0x2c/0x50 kernel/softirq.c:934 smpboot_thread_fn+0x554/0x9f0 kernel/smpboot.c:164 kthread+0x31b/0x430 kernel/kthread.c:376 ret_from_fork+0x1f/0x30Uninit was created at: slab_post_alloc_hook mm/slab.h:732 [inline] slab_alloc_node mm/slub.c:3258 [inline] __kmalloc_node_track_caller+0x814/0x1250 mm/slub.c:4970 kmalloc_reserve net/core/skbuff.c:358 [inline] __alloc_skb+0x346/0xcf0 net/core/skbuff.c:430 alloc_skb include/linux/skbuff.h:1257 [inline] nlmsg_new include/net/netlink.h:953 [inline] netlink_ack+0x5f3/0x12b0 net/netlink/af_netlink.c:2436 netlink_rcv_skb+0x55d/0x6c0 net/netlink/af_netlink.c:2507 rtnetlink_rcv+0x30/0x40 net/core/rtnetlink.c:6108 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] ____sys_sendmsg+0xabc/0xe90 net/socket.c:2482 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2536 __sys_sendmsg net/socket.c:2565 [inline] __do_sys_sendmsg net/socket.c:2574 [inline] __se_sys_sendmsg net/socket.c:2572 [inline] __x64_sys_sendmsg+0x367/0x540 net/socket.c:2572 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdCPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 6.0.0-rc2-syzkaller-47461-gac3859c02d7f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53022 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()This lockdep splat says it better than I could:================================WARNING: inconsistent lock state6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted--------------------------------inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes:ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0{IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64irq event stamp: 7825hardirqs last enabled at (7825): [] exit_to_kernel_mode+0x34/0x130hardirqs last disabled at (7823): [] __do_softirq+0x550/0x5d8softirqs last enabled at (7824): [] __do_softirq+0x46c/0x5d8softirqs last disabled at (7811): [] ____do_softirq+0x10/0x20other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); lock(_xmit_ETHER#2); *** DEADLOCK ***3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34Workqueue: events enetc_tx_onestep_tstampCall trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11cbut I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs inprocess context, therefore with softirqs enabled (i.o.w., it can beinterrupted by a softirq). If we hold the netif_tx_lock() when there isan interrupt, and the NET_TX softirq then gets scheduled, this will takethe netif_tx_lock() a second time and deadlock the kernel.To solve this, use netif_tx_lock_bh(), which blocks softirqs fromrunning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53031 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/imc-pmu: Fix use of mutex in IRQs disabled sectionCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEPand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.Command to trigger the warning: # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5 Performance counter stats for 'sleep 5': 0 thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ 5.002117947 seconds time elapsed 0.000131000 seconds user 0.001063000 seconds sysBelow is snippet of the warning in dmesg: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec preempt_count: 2, expected: 0 4 locks held by perf-exec/2869: #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90 #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0 #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510 #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510 irq event stamp: 4806 hardirqs last enabled at (4805): [] _raw_spin_unlock_irqrestore+0x94/0xd0 hardirqs last disabled at (4806): [] perf_event_exec+0x394/0x510 softirqs last enabled at (0): [] copy_process+0xc34/0x1ff0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV Call Trace: dump_stack_lvl+0x98/0xe0 (unreliable) __might_resched+0x2f8/0x310 __mutex_lock+0x6c/0x13f0 thread_imc_event_add+0xf4/0x1b0 event_sched_in+0xe0/0x210 merge_sched_in+0x1f0/0x600 visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0 ctx_flexible_sched_in+0xcc/0x140 ctx_sched_in+0x20c/0x2a0 ctx_resched+0x104/0x1c0 perf_event_exec+0x340/0x510 begin_new_exec+0x730/0xef0 load_elf_binary+0x3f8/0x1e10 ... do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0 WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0 CPU: 36 PID: 2869 Comm: sleep Tainted: G W 6.2.0-rc2-00011-g1247637727f2 #61 Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV NIP: c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670 REGS: c00000004d2134e0 TRAP: 0700 Tainted: G W (6.2.0-rc2-00011-g1247637727f2) MSR: 9000000000021033 CR: 48002824 XER: 00000000 CFAR: c00000000013fb64 IRQMASK: 1The above warning triggered because the current imc-pmu code uses mutexlock in interrupt disabled sections. The function mutex_lock()internally calls __might_resched(), which will check if IRQs aredisabled and in case IRQs are disabled, it will trigger the warning.Fix the issue by changing the mutex lock to spinlock.[mpe: Fix comments, trim oops in change log, add reported-by tags]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53032 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Fix overflow before widen in the bitmap_ip_create() function.When first_ip is 0, last_ip is 0xFFFFFFFF, and netmask is 31, the value ofan arithmetic expression 2 << (netmask - mask_bits - 1) is subjectto overflow due to a failure casting operands to a larger data typebefore performing the arithmetic.Note that it's harmless since the value will be checked at the next step.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix race condition in amdtee_open_sessionThere is a potential race condition in amdtee_open_session that maylead to use-after-free. For instance, in amdtee_open_session() aftersess->sess_mask is set, and before setting: sess->session_info[i] = session_info;if amdtee_close_session() closes this same session, then 'sess' datastructure will be released, causing kernel panic when 'sess' isaccessed within amdtee_open_session().The solution is to set the bit sess->sess_mask as the last step inamdtee_open_session().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: do not use skb_mac_header() in ndo_start_xmit()Drivers should not assume skb_mac_header(skb) == skb->data in theirndo_start_xmit().Use skb_network_offset() and skb_transport_offset() whichbetter describe what is needed in erspan_fb_xmit() andip6erspan_tunnel_xmit()syzbot reported:WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline]WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Modules linked in:CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline]RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:__netdev_start_xmit include/linux/netdevice.h:4900 [inline]netdev_start_xmit include/linux/netdevice.h:4914 [inline]__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300dev_direct_xmit include/linux/netdevice.h:3088 [inline]packet_xmit+0x20a/0x390 net/packet/af_packet.c:285packet_snd net/packet/af_packet.c:3075 [inline]packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg+0xde/0x190 net/socket.c:747__sys_sendto+0x23a/0x340 net/socket.c:2142__do_sys_sendto net/socket.c:2154 [inline]__se_sys_sendto net/socket.c:2150 [inline]__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f123aaa1039Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-vf: Add missing free for alloc_percpuAdd the free_percpu for the allocated "vf->hw.lmt_info" in order to avoidmemory leak, same as the "pf->hw.lmt_info" in`drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use the workqueue to destroy unaccepted socketsChristoph reported a UaF at token lookup time after havingrefactored the passive socket initialization part: BUG: KASAN: use-after-free in __token_bucket_busy+0x253/0x260 Read of size 4 at addr ffff88810698d5b0 by task syz-executor653/3198 CPU: 1 PID: 3198 Comm: syz-executor653 Not tainted 6.2.0-rc59af4eaa31c1f6c00c8f1e448ed99a45c66340dd5 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x6e/0x91 print_report+0x16a/0x46f kasan_report+0xad/0x130 __token_bucket_busy+0x253/0x260 mptcp_token_new_connect+0x13d/0x490 mptcp_connect+0x4ed/0x860 __inet_stream_connect+0x80e/0xd90 tcp_sendmsg_fastopen+0x3ce/0x710 mptcp_sendmsg+0xff1/0x1a20 inet_sendmsg+0x11d/0x140 __sys_sendto+0x405/0x490 __x64_sys_sendto+0xdc/0x1b0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcWe need to properly clean-up all the paired MPTCP-levelresources and be sure to release the msk last, even whenthe unaccepted subflow is destroyed by the TCP internalsvia inet_child_forget().We can re-use the existing MPTCP_WORK_CLOSE_SUBFLOW infra,explicitly checking that for the critical scenario: theclosed subflow is the MPC one, the msk is not accepted andeventually going through full cleanup.With such change, __mptcp_destroy_sock() is always calledon msk sockets, even on accepted ones. We don't need anymoreto transiently drop one sk reference at msk clone time.Please note this commit depends on the parent one: mptcp: refactor passive socket initialization

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Add missing overflow check in xdp_umem_regThe number of chunks can overflow u32. Make sure to return -EINVAL onoverflow. Also remove a redundant u32 cast assigning umem->npgs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: fsl_lpuart: fix race on RX DMA shutdownFrom time to time DMA completion can come in the middle of DMA shutdown:: :lpuart32_shutdown() lpuart_dma_shutdown() del_timer_sync() lpuart_dma_rx_complete() lpuart_copy_rx_to_tty() mod_timer() lpuart_dma_rx_free()When the timer fires a bit later, sport->dma_rx_desc is NULL:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004pc : lpuart_copy_rx_to_tty+0xcc/0x5bclr : lpuart_timer_func+0x1c/0x2cCall trace: lpuart_copy_rx_to_tty lpuart_timer_func call_timer_fn __run_timers.part.0 run_timer_softirq __do_softirq __irq_exit_rcu irq_exit handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler ...To fix this fold del_timer_sync() into lpuart_dma_rx_free() afterdmaengine_terminate_sync() to make sure timer will not be re-started inlpuart_copy_rx_to_tty() <= lpuart_dma_rx_complete().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53102 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: xsk: disable txq irq before flushing hwice_qp_dis() intends to stop a given queue pair that is a target of xskpool attach/detach. One of the steps is to disable interrupts on thesequeues. It currently is broken in a way that txq irq is turned off*after* HW flush which in turn takes no effect.ice_qp_dis():-> ice_qvec_dis_irq()--> disable rxq irq--> flush hw-> ice_vsi_stop_tx_ring()-->disable txq irqBelow splat can be triggered by following steps:- start xdpsock WITHOUT loading xdp prog- run xdp_rxq_info with XDP_TX action on this interface- start traffic- terminate xdpsock[ 256.312485] BUG: kernel NULL pointer dereference, address: 0000000000000018[ 256.319560] #PF: supervisor read access in kernel mode[ 256.324775] #PF: error_code(0x0000) - not-present page[ 256.329994] PGD 0 P4D 0[ 256.332574] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 256.337006] CPU: 3 PID: 32 Comm: ksoftirqd/3 Tainted: G OE 6.2.0-rc5+ #51[ 256.345218] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 256.355807] RIP: 0010:ice_clean_rx_irq_zc+0x9c/0x7d0 [ice][ 256.361423] Code: b7 8f 8a 00 00 00 66 39 ca 0f 84 f1 04 00 00 49 8b 47 40 4c 8b 24 d0 41 0f b7 45 04 66 25 ff 3f 66 89 04 24 0f 84 85 02 00 00 <49> 8b 44 24 18 0f b7 14 24 48 05 00 01 00 00 49 89 04 24 49 89 44[ 256.380463] RSP: 0018:ffffc900088bfd20 EFLAGS: 00010206[ 256.385765] RAX: 000000000000003c RBX: 0000000000000035 RCX: 000000000000067f[ 256.393012] RDX: 0000000000000775 RSI: 0000000000000000 RDI: ffff8881deb3ac80[ 256.400256] RBP: 000000000000003c R08: ffff889847982710 R09: 0000000000010000[ 256.407500] R10: ffffffff82c060c0 R11: 0000000000000004 R12: 0000000000000000[ 256.414746] R13: ffff88811165eea0 R14: ffffc9000d255000 R15: ffff888119b37600[ 256.421990] FS: 0000000000000000(0000) GS:ffff8897e0cc0000(0000) knlGS:0000000000000000[ 256.430207] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 256.436036] CR2: 0000000000000018 CR3: 0000000005c0a006 CR4: 00000000007706e0[ 256.443283] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 256.450527] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 256.457770] PKRU: 55555554[ 256.460529] Call Trace:[ 256.463015] [ 256.465157] ? ice_xmit_zc+0x6e/0x150 [ice][ 256.469437] ice_napi_poll+0x46d/0x680 [ice][ 256.473815] ? _raw_spin_unlock_irqrestore+0x1b/0x40[ 256.478863] __napi_poll+0x29/0x160[ 256.482409] net_rx_action+0x136/0x260[ 256.486222] __do_softirq+0xe8/0x2e5[ 256.489853] ? smpboot_thread_fn+0x2c/0x270[ 256.494108] run_ksoftirqd+0x2a/0x50[ 256.497747] smpboot_thread_fn+0x1c1/0x270[ 256.501907] ? __pfx_smpboot_thread_fn+0x10/0x10[ 256.506594] kthread+0xea/0x120[ 256.509785] ? __pfx_kthread+0x10/0x10[ 256.513597] ret_from_fork+0x29/0x50[ 256.517238] In fact, irqs were not disabled and napi managed to be scheduled and runwhile xsk_pool pointer was still valid, but SW ring of xdp_buff pointerswas already freed.To fix this, call ice_qvec_dis_irq() after ice_vsi_stop_tx_ring(). Alsowhile at it, remove redundant ice_clean_rx_ring() call - this is handledin ice_qp_clean_rings().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: restore bond's IFF_SLAVE flag if a non-eth dev enslave failssyzbot reported a warning[1] where the bond device itself is a slave andwe try to enslave a non-ethernet device as the first slave which failsbut then in the error path when ether_setup() restores the bond deviceit also clears all flags. In my previous fix[2] I restored theIFF_MASTER flag, but I didn't consider the case that the bond deviceitself might also be a slave with IFF_SLAVE set, so we need to restorethat flag as well. Use the bond_ether_setup helper which does the rightthing and restores the bond's flags properly.Steps to reproduce using a nlmon dev: $ ip l add nlmon0 type nlmon $ ip l add bond1 type bond $ ip l add bond2 type bond $ ip l set bond1 master bond2 $ ip l set dev nlmon0 master bond1 $ ip -d l sh dev bond1 22: bond1: mtu 1500 qdisc noqueue master bond2 state DOWN mode DEFAULT group default qlen 1000 (now bond1's IFF_SLAVE flag is gone and we'll hit a warning[3] if we try to delete it)[1] https://syzkaller.appspot.com/bug?id=391c7b1f6522182899efba27d891f1743e8eb3ef[2] commit 7d5cd2ce5292 ("bonding: correctly handle bonding type change on enslave failure")[3] example warning: [ 27.008664] bond1: (slave nlmon0): The slave device specified does not support setting the MAC address [ 27.008692] bond1: (slave nlmon0): Error -95 calling set_mac_address [ 32.464639] bond1 (unregistering): Released all slaves [ 32.464685] ------------[ cut here ]------------ [ 32.464686] WARNING: CPU: 1 PID: 2004 at net/core/dev.c:10829 unregister_netdevice_many+0x72a/0x780 [ 32.464694] Modules linked in: br_netfilter bridge bonding virtio_net [ 32.464699] CPU: 1 PID: 2004 Comm: ip Kdump: loaded Not tainted 5.18.0-rc3+ #47 [ 32.464703] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.1-2.fc37 04/01/2014 [ 32.464704] RIP: 0010:unregister_netdevice_many+0x72a/0x780 [ 32.464707] Code: 99 fd ff ff ba 90 1a 00 00 48 c7 c6 f4 02 66 96 48 c7 c7 20 4d 35 96 c6 05 fa c7 2b 02 01 e8 be 6f 4a 00 0f 0b e9 73 fd ff ff <0f> 0b e9 5f fd ff ff 80 3d e3 c7 2b 02 00 0f 85 3b fd ff ff ba 59 [ 32.464710] RSP: 0018:ffffa006422d7820 EFLAGS: 00010206 [ 32.464712] RAX: ffff8f6e077140a0 RBX: ffffa006422d7888 RCX: 0000000000000000 [ 32.464714] RDX: ffff8f6e12edbe58 RSI: 0000000000000296 RDI: ffffffff96d4a520 [ 32.464716] RBP: ffff8f6e07714000 R08: ffffffff96d63600 R09: ffffa006422d7728 [ 32.464717] R10: 0000000000000ec0 R11: ffffffff9698c988 R12: ffff8f6e12edb140 [ 32.464719] R13: dead000000000122 R14: dead000000000100 R15: ffff8f6e12edb140 [ 32.464723] FS: 00007f297c2f1740(0000) GS:ffff8f6e5d900000(0000) knlGS:0000000000000000 [ 32.464725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 32.464726] CR2: 00007f297bf1c800 CR3: 00000000115e8000 CR4: 0000000000350ee0 [ 32.464730] Call Trace: [ 32.464763] [ 32.464767] rtnl_dellink+0x13e/0x380 [ 32.464776] ? cred_has_capability.isra.0+0x68/0x100 [ 32.464780] ? __rtnl_unlock+0x33/0x60 [ 32.464783] ? bpf_lsm_capset+0x10/0x10 [ 32.464786] ? security_capable+0x36/0x50 [ 32.464790] rtnetlink_rcv_msg+0x14e/0x3b0 [ 32.464792] ? _copy_to_iter+0xb1/0x790 [ 32.464796] ? post_alloc_hook+0xa0/0x160 [ 32.464799] ? rtnl_calcit.isra.0+0x110/0x110 [ 32.464802] netlink_rcv_skb+0x50/0xf0 [ 32.464806] netlink_unicast+0x216/0x340 [ 32.464809] netlink_sendmsg+0x23f/0x480 [ 32.464812] sock_sendmsg+0x5e/0x60 [ 32.464815] ____sys_sendmsg+0x22c/0x270 [ 32.464818] ? import_iovec+0x17/0x20 [ 32.464821] ? sendmsg_copy_msghdr+0x59/0x90 [ 32.464823] ? do_set_pte+0xa0/0xe0 [ 32.464828] ___sys_sendmsg+0x81/0xc0 [ 32.464832] ? mod_objcg_state+0xc6/0x300 [ 32.464835] ? refill_obj_stock+0xa9/0x160 [ 32.464838] ? memcg_slab_free_hook+0x1a5/0x1f0 [ 32.464842] __sys_sendm---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53105 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix cleanup null-ptr deref on encap lockDuring module is unloaded while a peer tc flow is still offloaded,first the peer uplink rep profile is changed to a nic profile, and soneigh encap lock is destroyed. Next during unload, the VF reps netdevsare unregistered which causes the original non-peer tc flow to be deleted,which deletes the peer flow. The peer flow deletion detaches the encapentry and try to take the already destroyed encap lock, causing thebelow trace.Fix this by clearing peer flows during tc eswitch cleanup(mlx5e_tc_esw_cleanup()).Relevant trace:[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40[ 4316.851897] Call Trace:[ 4316.852481] [ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core][ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core][ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core][ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core][ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core][ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core][ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core][ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core][ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core][ 4316.865486] tc_setup_cb_reoffload+0x20/0x80[ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower][ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0[ 4316.869649] tcf_block_unbind+0xe7/0x1b0[ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270[ 4316.879266] tcf_block_offload_unbind+0x61/0xa0[ 4316.879711] __tcf_block_put+0xa4/0x310

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tunnels: annotate lockless accesses to dev->needed_headroomIP tunnels can apparently update dev->needed_headroomin their xmit path.This patch takes care of three tunnels xmit, and also thecore LL_RESERVED_SPACE() and LL_RESERVED_SPACE_EXTRA()helpers.More changes might be needed for completeness.BUG: KCSAN: data-race in ip_tunnel_xmit / ip_tunnel_xmitread to 0xffff88815b9da0ec of 2 bytes by task 888 on cpu 1:ip_tunnel_xmit+0x1270/0x1730 net/ipv4/ip_tunnel.c:803__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/ipv4/ip_output.c:430dst_output include/net/dst.h:444 [inline]ip_local_out+0x64/0x80 net/ipv4/ip_output.c:126iptunnel_xmit+0x34a/0x4b0 net/ipv4/ip_tunnel_core.c:82ip_tunnel_xmit+0x1451/0x1730 net/ipv4/ip_tunnel.c:813__gre_xmit net/ipv4/ip_gre.c:469 [inline]ipgre_xmit+0x516/0x570 net/ipv4/ip_gre.c:661__netdev_start_xmit include/linux/netdevice.h:4881 [inline]netdev_start_xmit include/linux/netdevice.h:4895 [inline]xmit_one net/core/dev.c:3580 [inline]dev_hard_start_xmit+0x127/0x400 net/core/dev.c:3596__dev_queue_xmit+0x1007/0x1eb0 net/core/dev.c:4246dev_queue_xmit include/linux/netdevice.h:3051 [inline]neigh_direct_output+0x17/0x20 net/core/neighbour.c:1623neigh_output include/net/neighbour.h:546 [inline]ip_finish_output2+0x740/0x840 net/ipv4/ip_output.c:228ip_finish_output+0xf4/0x240 net/ipv4/ip_output.c:316NF_HOOK_COND include/linux/netfilter.h:291 [inline]ip_output+0xe5/0x1b0 net/i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix NULL sndbuf_desc in smc_cdc_tx_handler()When performing a stress test on SMC-R by rmmod mlx5_ib driverduring the wrk/nginx test, we found that there is a probabilityof triggering a panic while terminating all link groups.This issue dues to the race between smc_smcr_terminate_all()and smc_buf_create(). smc_smcr_terminate_allsmc_buf_create/* init */conn->sndbuf_desc = NULL;... __smc_lgr_terminate smc_conn_kill smc_close_abort smc_cdc_get_slot_and_msg_send __softirqentry_text_start smc_wr_tx_process_cqe smc_cdc_tx_handler READ(conn->sndbuf_desc->len); /* panic dues to NULL sndbuf_desc */conn->sndbuf_desc = xxx;This patch tries to fix the issue by always to check the sndbuf_descbefore send any cdc msg, to make sure that no null pointer isseen during cqe processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: tcp_make_synack() can be called from process contexttcp_rtx_synack() now could be called in process context as explained in0a375c822497 ("tcp: tcp_rtx_synack() can be called from processcontext").tcp_rtx_synack() might call tcp_make_synack(), which will touch per-CPUvariables with preemption enabled. This causes the following BUG: BUG: using __this_cpu_add() in preemptible [00000000] code: ThriftIO1/5464 caller is tcp_make_synack+0x841/0xac0 Call Trace: dump_stack_lvl+0x10d/0x1a0 check_preemption_disabled+0x104/0x110 tcp_make_synack+0x841/0xac0 tcp_v6_send_synack+0x5c/0x450 tcp_rtx_synack+0xeb/0x1f0 inet_rtx_syn_ack+0x34/0x60 tcp_check_req+0x3af/0x9e0 tcp_rcv_state_process+0x59b/0x2030 tcp_v6_do_rcv+0x5f5/0x700 release_sock+0x3a/0xf0 tcp_sendmsg+0x33/0x40 ____sys_sendmsg+0x2f2/0x490 __sys_sendmsg+0x184/0x230 do_syscall_64+0x3d/0x90Avoid calling __TCP_INC_STATS() with will touch per-cpu variables. UseTCP_INC_STATS() which is safe to be called from context switch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix an infinite loop error when len is 0 in tcp_bpf_recvmsg_parser()When the buffer length of the recvmsg system call is 0, we got theflollowing soft lockup problem:watchdog: BUG: soft lockup - CPU#3 stuck for 27s! [a.out:6149]CPU: 3 PID: 6149 Comm: a.out Kdump: loaded Not tainted 6.2.0+ #30Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:remove_wait_queue+0xb/0xc0Code: 5e 41 5f c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 57 <41> 56 41 55 41 54 55 48 89 fd 53 48 89 f3 4c 8d 6b 18 4c 8d 73 20RSP: 0018:ffff88811b5978b8 EFLAGS: 00000246RAX: 0000000000000000 RBX: ffff88811a7d3780 RCX: ffffffffb7a4d768RDX: dffffc0000000000 RSI: ffff88811b597908 RDI: ffff888115408040RBP: 1ffff110236b2f1b R08: 0000000000000000 R09: ffff88811a7d37e7R10: ffffed10234fa6fc R11: 0000000000000001 R12: ffff88811179b800R13: 0000000000000001 R14: ffff88811a7d38a8 R15: ffff88811a7d37e0FS: 00007f6fb5398740(0000) GS:ffff888237180000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000010b6ba002 CR4: 0000000000370ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tcp_msg_wait_data+0x279/0x2f0 tcp_bpf_recvmsg_parser+0x3c6/0x490 inet_recvmsg+0x280/0x290 sock_recvmsg+0xfc/0x120 ____sys_recvmsg+0x160/0x3d0 ___sys_recvmsg+0xf0/0x180 __sys_recvmsg+0xea/0x1a0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThe logic in tcp_bpf_recvmsg_parser is as follows:msg_bytes_ready: copied = sk_msg_recvmsg(sk, psock, msg, len, flags); if (!copied) { wait data; goto msg_bytes_ready; }In this case, "copied" always is 0, the infinite loop occurs.According to the Linux system call man page, 0 should be returned in thiscase. Therefore, in tcp_bpf_recvmsg_parser(), if the length is 0, directlyreturn. Also modify several other functions with the same problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53135 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:riscv: Use READ_ONCE_NOCHECK in imprecise unwinding stack modeWhen CONFIG_FRAME_POINTER is unset, the stack unwinding functionwalk_stackframe randomly reads the stack and then, when KASAN is enabled,it can lead to the following backtrace:[ 0.000000] ==================================================================[ 0.000000] BUG: KASAN: stack-out-of-bounds in walk_stackframe+0xa6/0x11a[ 0.000000] Read of size 8 at addr ffffffff81807c40 by task swapper/0[ 0.000000][ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.2.0-12919-g24203e6db61f #43[ 0.000000] Hardware name: riscv-virtio,qemu (DT)[ 0.000000] Call Trace:[ 0.000000] [] walk_stackframe+0x0/0x11a[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] dump_stack_lvl+0x22/0x36[ 0.000000] [] print_report+0x198/0x4a8[ 0.000000] [] init_param_lock+0x26/0x2a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] kasan_report+0x9a/0xc8[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] walk_stackframe+0xa2/0x11a[ 0.000000] [] desc_make_final+0x80/0x84[ 0.000000] [] stack_trace_save+0x88/0xa6[ 0.000000] [] filter_irq_stacks+0x72/0x76[ 0.000000] [] devkmsg_read+0x32a/0x32e[ 0.000000] [] kasan_save_stack+0x28/0x52[ 0.000000] [] desc_make_final+0x7c/0x84[ 0.000000] [] stack_trace_save+0x84/0xa6[ 0.000000] [] kasan_set_track+0x12/0x20[ 0.000000] [] __kasan_slab_alloc+0x58/0x5e[ 0.000000] [] __kmem_cache_create+0x21e/0x39a[ 0.000000] [] create_boot_cache+0x70/0x9c[ 0.000000] [] kmem_cache_init+0x6c/0x11e[ 0.000000] [] mm_init+0xd8/0xfe[ 0.000000] [] start_kernel+0x190/0x3ca[ 0.000000][ 0.000000] The buggy address belongs to stack of task swapper/0[ 0.000000] and is located at offset 0 in frame:[ 0.000000] stack_trace_save+0x0/0xa6[ 0.000000][ 0.000000] This frame has 1 object:[ 0.000000] [32, 56) 'c'[ 0.000000][ 0.000000] The buggy address belongs to the physical page:[ 0.000000] page:(____ptrval____) refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x81a07[ 0.000000] flags: 0x1000(reserved|zone=0)[ 0.000000] raw: 0000000000001000 ff600003f1e3d150 ff600003f1e3d150 0000000000000000[ 0.000000] raw: 0000000000000000 0000000000000000 00000001ffffffff[ 0.000000] page dumped because: kasan: bad access detected[ 0.000000][ 0.000000] Memory state around the buggy address:[ 0.000000] ffffffff81807b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] >ffffffff81807c00: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f3[ 0.000000] ^[ 0.000000] ffffffff81807c80: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ffffffff81807d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[ 0.000000] ==================================================================Fix that by using READ_ONCE_NOCHECK when reading the stack in imprecisemode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53138 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: caif: Fix use-after-free in cfusbl_device_notify()syzbot reported use-after-free in cfusbl_device_notify() [1]. Thiscauses a stack trace like below:BUG: KASAN: use-after-free in cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138Read of size 8 at addr ffff88807ac4e6f0 by task kworker/u4:6/1214CPU: 0 PID: 1214 Comm: kworker/u4:6 Not tainted 5.19.0-rc3-syzkaller-00146-g92f20ff72066 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: netns cleanup_netCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x467 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 cfusbl_device_notify+0x7c9/0x870 net/caif/caif_usb.c:138 notifier_call_chain+0xb5/0x200 kernel/notifier.c:87 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:1945 call_netdevice_notifiers_extack net/core/dev.c:1983 [inline] call_netdevice_notifiers net/core/dev.c:1997 [inline] netdev_wait_allrefs_any net/core/dev.c:10227 [inline] netdev_run_todo+0xbc0/0x10f0 net/core/dev.c:10341 default_device_exit_batch+0x44e/0x590 net/core/dev.c:11334 ops_exit_list+0x125/0x170 net/core/net_namespace.c:167 cleanup_net+0x4ea/0xb00 net/core/net_namespace.c:594 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 When unregistering a net device, unregister_netdevice_many_notify()sets the device's reg_state to NETREG_UNREGISTERING, calls notifierswith NETDEV_UNREGISTER, and adds the device to the todo list.Later on, devices in the todo list are processed by netdev_run_todo().netdev_run_todo() waits devices' reference count become 1 whilerebdoadcasting NETDEV_UNREGISTER notification.When cfusbl_device_notify() is called with NETDEV_UNREGISTER multipletimes, the parent device might be freed. This could cause UAF.Processing NETDEV_UNREGISTER multiple times also causes inbalance ofreference count for the module.This patch fixes the issue by accepting only first NETDEV_UNREGISTERnotification.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53141 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: do not generate empty messages in ila_xlat_nl_cmd_get_mapping()ila_xlat_nl_cmd_get_mapping() generates an empty skb,triggerring a recent sanity check [1].Instead, return an error code, so that user spacecan get it.[1]skb_assert_lenWARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 skb_assert_len include/linux/skbuff.h:2527 [inline]WARNING: CPU: 0 PID: 5923 at include/linux/skbuff.h:2527 __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156Modules linked in:CPU: 0 PID: 5923 Comm: syz-executor269 Not tainted 6.2.0-syzkaller-18300-g2ebd1fbb946d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_assert_len include/linux/skbuff.h:2527 [inline]pc : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156lr : skb_assert_len include/linux/skbuff.h:2527 [inline]lr : __dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156sp : ffff80001e0d6c40x29: ffff80001e0d6e60 x28: dfff800000000000 x27: ffff0000c86328c0x26: dfff800000000000 x25: ffff0000c8632990 x24: ffff0000c8632a00x23: 0000000000000000 x22: 1fffe000190c6542 x21: ffff0000c8632a10x20: ffff0000c8632a00 x19: ffff80001856e000 x18: ffff80001e0d5fc0x17: 0000000000000000 x16: ffff80001235d16c x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000001x11: ff80800008353a30 x10: 0000000000000000 x9 : 21567eaf25bfb600x8 : 21567eaf25bfb600 x7 : 0000000000000001 x6 : 0000000000000001x5 : ffff80001e0d6558 x4 : ffff800015c74760 x3 : ffff800008596744x2 : 0000000000000001 x1 : 0000000100000000 x0 : 000000000000000eCall trace:skb_assert_len include/linux/skbuff.h:2527 [inline]__dev_queue_xmit+0x1bc0/0x3488 net/core/dev.c:4156dev_queue_xmit include/linux/netdevice.h:3033 [inline]__netlink_deliver_tap_skb net/netlink/af_netlink.c:307 [inline]__netlink_deliver_tap+0x45c/0x6f8 net/netlink/af_netlink.c:325netlink_deliver_tap+0xf4/0x174 net/netlink/af_netlink.c:338__netlink_sendskb net/netlink/af_netlink.c:1283 [inline]netlink_sendskb+0x6c/0x154 net/netlink/af_netlink.c:1292netlink_unicast+0x334/0x8d4 net/netlink/af_netlink.c:1380nlmsg_unicast include/net/netlink.h:1099 [inline]genlmsg_unicast include/net/genetlink.h:433 [inline]genlmsg_reply include/net/genetlink.h:443 [inline]ila_xlat_nl_cmd_get_mapping+0x620/0x7d0 net/ipv6/ila/ila_xlat.c:493genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline]genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline]genl_rcv_msg+0x938/0xc1c net/netlink/genetlink.c:1065netlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2574genl_rcv+0x38/0x50 net/netlink/genetlink.c:1076netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365netlink_sendmsg+0x800/0xae0 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:714 [inline]sock_sendmsg net/socket.c:734 [inline]____sys_sendmsg+0x558/0x844 net/socket.c:2479___sys_sendmsg net/socket.c:2533 [inline]__sys_sendmsg+0x26c/0x33c net/socket.c:2562__do_sys_sendmsg net/socket.c:2571 [inline]__se_sys_sendmsg net/socket.c:2569 [inline]__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2569__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]invoke_syscall+0x98/0x2c0 arch/arm64/kernel/syscall.c:52el0_svc_common+0x138/0x258 arch/arm64/kernel/syscall.c:142do_el0_svc+0x64/0x198 arch/arm64/kernel/syscall.c:193el0_svc+0x58/0x168 arch/arm64/kernel/entry-common.c:637el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591irq event stamp: 136484hardirqs last enabled at (136483): [] __up_console_sem+0x60/0xb4 kernel/printk/printk.c:345hardirqs last disabled at (136484): [] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:405softirqs last enabled at (136418): [] softirq_ha---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53146 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dw2102: Fix null-ptr-deref in dw2102_i2c_transfer()In dw2102_i2c_transfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach dw2102_i2c_transfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 950e252cb469("[media] dw2102: limit messages to buffer size")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53152 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix calltrace warning in amddrm_buddy_finiThe following call trace is observed when removing the amdgpu driver, whichis caused by that BOs allocated for psp are not freed until removing.[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy][61811.450577] Call Trace:[61811.450577] [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu][61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu][61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu][61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu][61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu][61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu][61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm][61811.451466] devm_action_release+0x15/0x20[61811.451469] release_nodes+0x40/0xb0[61811.451471] devres_release_all+0x9b/0xd0[61811.451473] __device_release_driver+0x1bb/0x2a0[61811.451476] driver_detach+0xf3/0x140[61811.451479] bus_remove_driver+0x6c/0xf0[61811.451481] driver_unregister+0x31/0x60[61811.451483] pci_unregister_driver+0x40/0x90[61811.451486] amdgpu_exit+0x15/0x447 [amdgpu]For smu v13_0_2, if the GPU supports xgmi, refer tocommit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"),it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,which makes all devices in hive list have hw reset but no resume except thebasic ip blocks, then other ip blocks will not call .hw_fini according toip_block.status.hw.Since psp_free_shared_bufs just includes some software operations, so moveit to psp_sw_fini.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53164 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/ti-sci: Fix refcount leak in ti_sci_intr_irq_domain_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53183 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: Fix a race between coalescing and releasing SKBsCommit 1effe8ca4e34 ("skbuff: fix coalescing for page_pool fragmentrecycling") allowed coalescing to proceed with non page pool page and pagepool page when @from is cloned, i.e.to->pp_recycle --> falsefrom->pp_recycle --> trueskb_cloned(from) --> trueHowever, it actually requires skb_cloned(@from) to hold true untilcoalescing finishes in this situation. If the other cloned SKB isreleased while the merging is in process, from_shinfo->nr_frags will beset to 0 toward the end of the function, causing the increment of fragpage _refcount to be unexpectedly skipped resulting in inconsistentreference counts. Later when SKB(@to) is released, it frees the pagedirectly even though the page pool page is still in use, leading touse-after-free or double-free errors. So it should be prohibited.The double-free error message below prompted us to investigate:BUG: Bad page state in process swapper/1 pfn:0e0d1page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000index:0x2 pfn:0xe0d1flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000page dumped because: nonzero _refcountCPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+Call Trace: dump_stack_lvl+0x32/0x50bad_page+0x69/0xf0free_pcp_prepare+0x260/0x2f0free_unref_page+0x20/0x1c0skb_release_data+0x10b/0x1a0napi_consume_skb+0x56/0x150net_rx_action+0xf0/0x350? __napi_schedule+0x79/0x90__do_softirq+0xc8/0x2b1__irq_exit_rcu+0xb9/0xf0common_interrupt+0x82/0xa0asm_common_interrupt+0x22/0x40RIP: 0010:default_idle+0xb/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53188 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix race on port outputassume the following setup on a single machine:1. An openvswitch instance with one bridge and default flows2. two network namespaces "server" and "client"3. two ovs interfaces "server" and "client" on the bridge4. for each ovs interface a veth pair with a matching name and 32 rx and tx queues5. move the ends of the veth pairs to the respective network namespaces6. assign ip addresses to each of the veth ends in the namespaces (needs to be the same subnet)7. start some http server on the server network namespace8. test if a client in the client namespace can reach the http serverwhen following the actions below the host has a chance of getting a cpustuck in a infinite loop:1. send a large amount of parallel requests to the http server (around 3000 curls should work)2. in parallel delete the network namespace (do not delete interfaces or stop the server, just kill the namespace)there is a low chance that this will cause the below kernel cpu stuckmessage. If this does not happen just retry.Below there is also the output of bpftrace for the functions mentionedin the output.The series of events happening here is:1. the network namespace is deleted calling `unregister_netdevice_many_notify` somewhere in the process2. this sets first `NETREG_UNREGISTERING` on both ends of the veth and then runs `synchronize_net`3. it then calls `call_netdevice_notifiers` with `NETDEV_UNREGISTER`4. this is then handled by `dp_device_event` which calls `ovs_netdev_detach_dev` (if a vport is found, which is the case for the veth interface attached to ovs)5. this removes the rx_handlers of the device but does not prevent packages to be sent to the device6. `dp_device_event` then queues the vport deletion to work in background as a ovs_lock is needed that we do not hold in the unregistration path7. `unregister_netdevice_many_notify` continues to call `netdev_unregister_kobject` which sets `real_num_tx_queues` to 08. port deletion continues (but details are not relevant for this issue)9. at some future point the background task deletes the vportIf after 7. but before 9. a packet is send to the ovs vport (which isnot deleted at this point in time) which forwards it to the`dev_queue_xmit` flow even though the device is unregistering.In `skb_tx_hash` (which is called in the `dev_queue_xmit`) path there isa while loop (if the packet has a rx_queue recorded) that is infinite if`dev->real_num_tx_queues` is zero.To prevent this from happening we update `do_output` to handle deviceswithout carrier the same as if the device is not found (which wouldbe the code path after 9. is done).Additionally we now produce a warning in `skb_tx_hash` if we will hitthe infinite loop.bpftrace (first word is function name):__dev_queue_xmit server: real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1netdev_core_pick_tx server: addr: 0xffff9f0a46d4a000 real_num_tx_queues: 1, cpu: 2, pid: 28024, tid: 28024, skb_addr: 0xffff9edb6f207000, reg_state: 1dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 2, reg_state: 1synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024dp_device_event server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, event 6, reg_state: 2ovs_netdev_detach_dev server: real_num_tx_queues: 1 cpu 9, pid: 21024, tid: 21024, reg_state: 2netdev_rx_handler_unregister server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2synchronize_rcu_expedited: cpu 9, pid: 21024, tid: 21024netdev_rx_handler_unregister ret server: real_num_tx_queues: 1, cpu: 9, pid: 21024, tid: 21024, reg_state: 2dp_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53189 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6/addrconf: fix a potential refcount underflow for idevNow in addrconf_mod_rs_timer(), reference idev depends on whetherrs_timer is not pending. Then modify rs_timer timeout.There is a time gap in [1], during which if the pending rs_timerbecomes not pending. It will miss to hold idev, but the rs_timeris activated. Thus rs_timer callback function addrconf_rs_timer()will be executed and put idev later without holding idev. A refcountunderflow issue for idev can be caused by this. if (!timer_pending(&idev->rs_timer)) in6_dev_hold(idev); <--------------[1] mod_timer(&idev->rs_timer, jiffies + when);To fix the issue, hold idev if mod_timer() return 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/alpine-msi: Fix refcount leak in alpine_msix_init_domainsof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix nexthop hash sizeThe nexthop code expects a 31 bit hash, such as what is returned byfib_multipath_hash() and rt6_multipath_hash(). Passing the 32 bit hashreturned by skb_get_hash() can lead to problems related to the fact that'int hash' is a negative number when the MSB is set.In the case of hash threshold nexthop groups, nexthop_select_path_hthr()will disproportionately select the first nexthop group entry. In the caseof resilient nexthop groups, nexthop_select_path_res() may do an out ofbounds access in nh_buckets[], for example: hash = -912054133 num_nh_buckets = 2 bucket_index = 65535which leads to the following panic:BUG: unable to handle page fault for address: ffffc900025910c8PGD 100000067 P4D 100000067 PUD 10026b067 PMD 0Oops: 0002 [#1] PREEMPT SMP KASAN NOPTICPU: 4 PID: 856 Comm: kworker/4:3 Not tainted 6.5.0-rc2+ #34Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:nexthop_select_path+0x197/0xbf0Code: c1 e4 05 be 08 00 00 00 4c 8b 35 a4 14 7e 01 4e 8d 6c 25 00 4a 8d 7c 25 08 48 01 dd e8 c2 25 15 ff 49 8d 7d 08 e8 39 13 15 ff <4d> 89 75 08 48 89 ef e8 7d 12 15 ff 48 8b 5d 00 e8 14 55 2f 00 85RSP: 0018:ffff88810c36f260 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000002000c0 RCX: ffffffffaf02dd77RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffffc900025910c8RBP: ffffc900025910c0 R08: 0000000000000001 R09: fffff520004b2219R10: ffffc900025910cf R11: 31392d2068736168 R12: 00000000002000c0R13: ffffc900025910c0 R14: 00000000fffef608 R15: ffff88811840e900FS: 0000000000000000(0000) GS:ffff8881f7000000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc900025910c8 CR3: 0000000129d00000 CR4: 0000000000750ee0PKRU: 55555554Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x1ee/0x5c0 ? __pfx_is_prefetch.constprop.0+0x10/0x10 ? __pfx_page_fault_oops+0x10/0x10 ? search_bpf_extables+0xfe/0x1c0 ? fixup_exception+0x3b/0x470 ? exc_page_fault+0xf6/0x110 ? asm_exc_page_fault+0x26/0x30 ? nexthop_select_path+0x197/0xbf0 ? nexthop_select_path+0x197/0xbf0 ? lock_is_held_type+0xe7/0x140 vxlan_xmit+0x5b2/0x2340 ? __lock_acquire+0x92b/0x3370 ? __pfx_vxlan_xmit+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_register_lock_class+0x10/0x10 ? skb_network_protocol+0xce/0x2d0 ? dev_hard_start_xmit+0xca/0x350 ? __pfx_vxlan_xmit+0x10/0x10 dev_hard_start_xmit+0xca/0x350 __dev_queue_xmit+0x513/0x1e20 ? __pfx___dev_queue_xmit+0x10/0x10 ? __pfx_lock_release+0x10/0x10 ? mark_held_locks+0x44/0x90 ? skb_push+0x4c/0x80 ? eth_header+0x81/0xe0 ? __pfx_eth_header+0x10/0x10 ? neigh_resolve_output+0x215/0x310 ? ip6_finish_output2+0x2ba/0xc90 ip6_finish_output2+0x2ba/0xc90 ? lock_release+0x236/0x3e0 ? ip6_mtu+0xbb/0x240 ? __pfx_ip6_finish_output2+0x10/0x10 ? find_held_lock+0x83/0xa0 ? lock_is_held_type+0xe7/0x140 ip6_finish_output+0x1ee/0x780 ip6_output+0x138/0x460 ? __pfx_ip6_output+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_ip6_finish_output+0x10/0x10 NF_HOOK.constprop.0+0xc0/0x420 ? __pfx_NF_HOOK.constprop.0+0x10/0x10 ? ndisc_send_skb+0x2c0/0x960 ? __pfx_lock_release+0x10/0x10 ? __local_bh_enable_ip+0x93/0x110 ? lock_is_held_type+0xe7/0x140 ndisc_send_skb+0x4be/0x960 ? __pfx_ndisc_send_skb+0x10/0x10 ? mark_held_locks+0x65/0x90 ? find_held_lock+0x83/0xa0 ndisc_send_ns+0xb0/0x110 ? __pfx_ndisc_send_ns+0x10/0x10 addrconf_dad_work+0x631/0x8e0 ? lock_acquire+0x180/0x3f0 ? __pfx_addrconf_dad_work+0x10/0x10 ? mark_held_locks+0x24/0x90 process_one_work+0x582/0x9c0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x24/0x90 worker_thread+0x93/0x630 ? __kthread_parkme+0xdc/0x100 ? __pfx_worker_thread+0x10/0x10 kthread+0x1a5/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: domains: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-races around user->unix_inflight.user->unix_inflight is changed under spin_lock(unix_gc_lock),but too_many_unix_fds() reads it locklessly.Let's annotate the write/read accesses to user->unix_inflight.BUG: KCSAN: data-race in unix_attach_fds / unix_inflightwrite to 0xffffffff8546f2d0 of 8 bytes by task 44798 on cpu 1: unix_inflight+0x157/0x180 net/unix/scm.c:66 unix_attach_fds+0x147/0x1e0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8read to 0xffffffff8546f2d0 of 8 bytes by task 44814 on cpu 0: too_many_unix_fds net/unix/scm.c:101 [inline] unix_attach_fds+0x54/0x1e0 net/unix/scm.c:110 unix_scm_to_skb net/unix/af_unix.c:1827 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1950 unix_seqpacket_sendmsg net/unix/af_unix.c:2308 [inline] unix_seqpacket_sendmsg+0xba/0x130 net/unix/af_unix.c:2292 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x148/0x160 net/socket.c:748 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2494 ___sys_sendmsg+0xc6/0x140 net/socket.c:2548 __sys_sendmsg+0x94/0x140 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2584 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x6e/0xd8value changed: 0x000000000000000c -> 0x000000000000000dReported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 44814 Comm: systemd-coredum Not tainted 6.4.0-11989-g6843306689af #6Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nubus: Partially revert proc_create_single_data() conversionThe conversion to proc_create_single_data() introduced a regressionwhereby reading a file in /proc/bus/nubus results in a seg fault: # grep -r . /proc/bus/nubus/e/ Data read fault at 0x00000020 in Super Data (pc=0x1074c2) BAD KERNEL BUSERR Oops: 00000000 Modules linked in: PC: [<001074c2>] PDE_DATA+0xc/0x16 SR: 2010 SP: 38284958 a2: 01152370 d0: 00000001 d1: 01013000 d2: 01002790 d3: 00000000 d4: 00000001 d5: 0008ce2e a0: 00000000 a1: 00222a40 Process grep (pid: 45, task=142f8727) Frame format=B ssw=074d isc=2008 isb=4e5e daddr=00000020 dobuf=01199e70 baddr=001074c8 dibuf=ffffffff ver=f Stack from 01199e48: 01199e70 00222a58 01002790 00000000 011a3000 01199eb0 015000c0 00000000 00000000 01199ec0 01199ec0 000d551a 011a3000 00000001 00000000 00018000 d003f000 00000003 00000001 0002800d 01052840 01199fa8 c01f8000 00000000 00000029 0b532b80 00000000 00000000 00000029 0b532b80 01199ee4 00103640 011198c0 d003f000 00018000 01199fa8 00000000 011198c0 00000000 01199f4c 000b3344 011198c0 d003f000 00018000 01199fa8 00000000 00018000 011198c0 Call Trace: [<00222a58>] nubus_proc_rsrc_show+0x18/0xa0 [<000d551a>] seq_read+0xc4/0x510 [<00018000>] fp_fcos+0x2/0x82 [<0002800d>] __sys_setreuid+0x115/0x1c6 [<00103640>] proc_reg_read+0x5c/0xb0 [<00018000>] fp_fcos+0x2/0x82 [<000b3344>] __vfs_read+0x2c/0x13c [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b8aa2>] sys_statx+0x60/0x7e [<000b34b6>] vfs_read+0x62/0x12a [<00018000>] fp_fcos+0x2/0x82 [<00018000>] fp_fcos+0x2/0x82 [<000b39c2>] ksys_read+0x48/0xbe [<00018000>] fp_fcos+0x2/0x82 [<000b3a4e>] sys_read+0x16/0x1a [<00018000>] fp_fcos+0x2/0x82 [<00002b84>] syscall+0x8/0xc [<00018000>] fp_fcos+0x2/0x82 [<0000c016>] not_ext+0xa/0x18 Code: 4e5e 4e75 4e56 0000 206e 0008 2068 ffe8 <2068> 0020 2008 4e5e 4e75 4e56 0000 2f0b 206e 0008 2068 0004 2668 0020 206b ffe8 Disabling lock debugging due to kernel taint Segmentation faultThe proc_create_single_data() conversion does not work becausesingle_open(file, nubus_proc_rsrc_show, PDE_DATA(inode)) is notequivalent to the original code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Make it so that a waiting process can be abortedWhen sendmsg() creates an rxrpc call, it queues it to wait for a connectionand channel to be assigned and then waits before it can start shovellingdata as the encrypted DATA packet content includes a summary of theconnection parameters.However, sendmsg() may get interrupted before a connection gets assignedand further sendmsg() calls will fail with EBUSY until an assignment ismade.Fix this so that the call can at least be aborted without failing onEBUSY. We have to be careful here as sendmsg() mustn't be allowed to startthe call timer if the call doesn't yet have a connection assigned as anoops may follow shortly thereafter.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53221 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix memleak due to fentry attach failureIf it fails to attach fentry, the allocated bpf trampoline image will beleft in the system. That can be verified by checking /proc/kallsyms.This meamleak can be verified by a simple bpf program as follows: SEC("fentry/trap_init") int fentry_run() { return 0; }It will fail to attach trap_init because this function is freed afterkernel init, and then we can find the trampoline image is left in thesystem by checking /proc/kallsyms. $ tail /proc/kallsyms ffffffffc0613000 t bpf_trampoline_6442453466_1 [bpf] ffffffffc06c3000 t bpf_trampoline_6442453466_1 [bpf] $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep "FUNC 'trap_init'" [2522] FUNC 'trap_init' type_id=119 linkage=static $ echo $((6442453466 & 0x7fffffff)) 2522Note that there are two left bpf trampoline images, that is because thelibbpf will fallback to raw tracepoint if -EINVAL is returned.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: Fix function prototype mismatch for ext4_feat_ktypeWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),indirect call targets are validated against the expected functionpointer prototype to make sure the call target is valid to help mitigateROP attacks. If they are not identical, there is a failure at run time,which manifests as either a kernel panic or thread getting killed.ext4_feat_ktype was setting the "release" handler to "kfree", whichdoesn't have a matching function prototype. Add a simple wrapperwith the correct prototype.This was found as a result of Clang's new -Wcast-function-type-strictflag, which is more sensitive than the simpler -Wcast-function-type,which only checks for type width mismatches.Note that this code is only reached when ext4 is a loadable module andit is being unloaded: CFI failure at kobject_put+0xbb/0x1b0 (target: kfree+0x0/0x180; expected type: 0x7c4aa698) ... RIP: 0010:kobject_put+0xbb/0x1b0 ... Call Trace: ext4_exit_sysfs+0x14/0x60 [ext4] cleanup_module+0x67/0xedb [ext4]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: Fix detection of atomic contextCurrent check for atomic context is not sufficient asz_erofs_decompressqueue_endio can be called under rcu lockfrom blk_mq_flush_plug_list(). See the stacktrace [1]In such case we should hand off the decompression work for asyncprocessing rather than trying to do sync decompression in currentcontext. Patch fixes the detection by checking forrcu_read_lock_any_held() and while at it use more appropriate!in_task() check than in_atomic().Background: Historically erofs would always schedule a kworker fordecompression which would incur the scheduling cost regardless ofthe context. But z_erofs_decompressqueue_endio() may not alwaysbe in atomic context and we could actually benefit from doing thedecompression in z_erofs_decompressqueue_endio() if we are inthread context, for example when running with dm-verity.This optimization was later added in patch [2] which has shownimprovement in performance benchmarks.==============================================[1] Problem stacktrace[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi[name:core&]preempt_count: 0, expected: 0[name:core&]RCU nest depth: 1, expected: 0CPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S W OE 6.1.25-android14-5-maybe-dirty-mainline #1Hardware name: MT6897 (DT)Call trace: dump_backtrace+0x108/0x15c show_stack+0x20/0x30 dump_stack_lvl+0x6c/0x8c dump_stack+0x20/0x48 __might_resched+0x1fc/0x308 __might_sleep+0x50/0x88 mutex_lock+0x2c/0x110 z_erofs_decompress_queue+0x11c/0xc10 z_erofs_decompress_kickoff+0x110/0x1a4 z_erofs_decompressqueue_endio+0x154/0x180 bio_endio+0x1b0/0x1d8 __dm_io_complete+0x22c/0x280 clone_endio+0xe4/0x280 bio_endio+0x1b0/0x1d8 blk_update_request+0x138/0x3a4 blk_mq_plug_issue_direct+0xd4/0x19c blk_mq_flush_plug_list+0x2b0/0x354 __blk_flush_plug+0x110/0x160 blk_finish_plug+0x30/0x4c read_pages+0x2fc/0x370 page_cache_ra_unbounded+0xa4/0x23c page_cache_ra_order+0x290/0x320 do_sync_mmap_readahead+0x108/0x2c0 filemap_fault+0x19c/0x52c __do_fault+0xc4/0x114 handle_mm_fault+0x5b4/0x1168 do_page_fault+0x338/0x4b4 do_translation_fault+0x40/0x60 do_mem_abort+0x60/0xc8 el0_da+0x4c/0xe0 el0t_64_sync_handler+0xd4/0xfc el0t_64_sync+0x1a0/0x1a4[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix deadlock triggered by cancel_delayed_work_syn()The following LOCKDEP was detected: Workqueue: events smc_lgr_free_work [smc] WARNING: possible circular locking dependency detected 6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted ------------------------------------------------------ kworker/3:0/176251 is trying to acquire lock: 00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}, at: __flush_workqueue+0x7a/0x4f0 but task is already holding lock: 0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_work+0x76/0xf0 __cancel_work_timer+0x170/0x220 __smc_lgr_terminate.part.0+0x34/0x1c0 [smc] smc_connect_rdma+0x15e/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #3 (smc_client_lgr_pending){+.+.}-{3:3}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __mutex_lock+0x96/0x8e8 mutex_lock_nested+0x32/0x40 smc_connect_rdma+0xa4/0x418 [smc] __smc_connect+0x234/0x480 [smc] smc_connect+0x1d6/0x230 [smc] __sys_connect+0x90/0xc0 __do_sys_socketcall+0x186/0x370 __do_syscall+0x1da/0x208 system_call+0x82/0xb0 -> #2 (sk_lock-AF_SMC){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 lock_sock_nested+0x46/0xa8 smc_tx_work+0x34/0x50 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}: __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 process_one_work+0x2bc/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 -> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}: check_prev_add+0xd8/0xe88 validate_chain+0x70c/0xb20 __lock_acquire+0x58e/0xbd8 lock_acquire.part.0+0xe2/0x248 lock_acquire+0xac/0x1c8 __flush_workqueue+0xaa/0x4f0 drain_workqueue+0xaa/0x158 destroy_workqueue+0x44/0x2d8 smc_lgr_free+0x9e/0xf8 [smc] process_one_work+0x30c/0x730 worker_thread+0x62/0x420 kthread+0x138/0x150 __ret_from_fork+0x3c/0x58 ret_from_fork+0xa/0x40 other info that might help us debug this: Chain exists of: (wq_completion)smc_tx_wq-00000000#2 --> smc_client_lgr_pending --> (work_completion)(&(&lgr->free_work)->work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&(&lgr->free_work)->work)); lock(smc_client_lgr_pending); lock((work_completion) (&(&lgr->free_work)->work)); lock((wq_completion)smc_tx_wq-00000000#2); *** DEADLOCK *** 2 locks held by kworker/3:0/176251: #0: 0000000080183548 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x232/0x730 #1: 0000037fffe97dc8 ((work_completion) (&(&lgr->free_work)->work)){+.+.}-{0:0}, at: process_one_work+0x232/0x730 stack backtr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: set_page_extent_mapped after read_folio in btrfs_cont_expandWhile trying to get the subpage blocksize tests running, I hit thefollowing panic on generic/476 assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229 kernel BUG at fs/btrfs/subpage.c:229! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023 pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : btrfs_subpage_assert+0xbc/0xf0 lr : btrfs_subpage_assert+0xbc/0xf0 Call trace: btrfs_subpage_assert+0xbc/0xf0 btrfs_subpage_clear_checked+0x38/0xc0 btrfs_page_clear_checked+0x48/0x98 btrfs_truncate_block+0x5d0/0x6a8 btrfs_cont_expand+0x5c/0x528 btrfs_write_check.isra.0+0xf8/0x150 btrfs_buffered_write+0xb4/0x760 btrfs_do_write_iter+0x2f8/0x4b0 btrfs_file_write_iter+0x1c/0x30 do_iter_readv_writev+0xc8/0x158 do_iter_write+0x9c/0x210 vfs_iter_write+0x24/0x40 iter_file_splice_write+0x224/0x390 direct_splice_actor+0x38/0x68 splice_direct_to_actor+0x12c/0x260 do_splice_direct+0x90/0xe8 generic_copy_file_range+0x50/0x90 vfs_copy_file_range+0x29c/0x470 __arm64_sys_copy_file_range+0xcc/0x498 invoke_syscall.constprop.0+0x80/0xd8 do_el0_svc+0x6c/0x168 el0_svc+0x50/0x1b0 el0t_64_sync_handler+0x114/0x120 el0t_64_sync+0x194/0x198This happens because during btrfs_cont_expand we'll get a page, set itas mapped, and if it's not Uptodate we'll read it. However between theread and re-locking the page we could have called release_folio() on thepage, but left the page in the file mapping. release_folio() can clearthe page private, and thus further down we blow up when we go to modifythe subpage bits.Fix this by putting the set_page_extent_mapped() after the read. Thisis safe because read_folio() will call set_page_extent_mapped() beforeit does the read, and then if we clear page private but leave it on themapping we're completely safe re-setting set_page_extent_mapped(). Withthis patch I can now run generic/476 without panicing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Put the cdns set active part outside the spin lockThe device may be scheduled during the resume process,so this cannot appear in atomic operations. Sincepm_runtime_set_active will resume suppliers, put setactive outside the spin lock, which is only used toprotect the struct cdns data structure, otherwise thekernel will report the following warning: BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 CPU: 0 PID: 651 Comm: sh Tainted: G WC 6.1.20 #1 Hardware name: Freescale i.MX8QM MEK (DT) Call trace: dump_backtrace.part.0+0xe0/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x64/0x80 dump_stack+0x1c/0x38 __might_resched+0x1fc/0x240 __might_sleep+0x68/0xc0 __pm_runtime_resume+0x9c/0xe0 rpm_get_suppliers+0x68/0x1b0 __pm_runtime_set_status+0x298/0x560 cdns_resume+0xb0/0x1c0 cdns3_controller_resume.isra.0+0x1e0/0x250 cdns3_plat_resume+0x28/0x40

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: bdisp: Add missing check for create_workqueueAdd the check for the return value of the create_workqueuein order to avoid NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu/rcuscale: Stop kfree_scale_thread thread(s) after unloading rcuscaleRunning the 'kfree_rcu_test' test case [1] results in a splat [2].The root cause is the kfree_scale_thread thread(s) continue runningafter unloading the rcuscale module. This commit fixes that isue byinvoking kfree_scale_cleanup() from rcu_scale_cleanup() when removingthe rcuscale module.[1] modprobe rcuscale kfree_rcu_test=1 // After some time rmmod rcuscale rmmod torture[2] BUG: unable to handle page fault for address: ffffffffc0601a87 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page PGD 11de4f067 P4D 11de4f067 PUD 11de51067 PMD 112f4d067 PTE 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 1798 Comm: kfree_scale_thr Not tainted 6.3.0-rc1-rcu+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 RIP: 0010:0xffffffffc0601a87 Code: Unable to access opcode bytes at 0xffffffffc0601a5d. RSP: 0018:ffffb25bc2e57e18 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffffffffc061f0b6 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff962fd0de RDI: ffffffff962fd0de RBP: ffffb25bc2e57ea8 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000000 R14: 000000000000000a R15: 00000000001c1dbe FS: 0000000000000000(0000) GS:ffff921fa2200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc0601a5d CR3: 000000011de4c006 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? kvfree_call_rcu+0xf0/0x3a0 ? kthread+0xf3/0x120 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x1f/0x30 Modules linked in: rfkill sunrpc ... [last unloaded: torture] CR2: ffffffffc0601a87 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Better handle pm_runtime_get() failing in .remove()In the (unlikely) event that pm_runtime_get() (disguised aspm_runtime_resume_and_get()) fails, the remove callback returned anerror early. The problem with this is that the driver core ignores theerror value and continues removing the device. This results in aresource leak. Worse the devm allocated resources are freed and so if acallback of the driver is called later the register mapping is alreadygone which probably results in a crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:recordmcount: Fix memory leaks in the uwrite functionCommon realloc mistake: 'file_append' nulled but not freed upon failure

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/ipi: Fix NULL pointer deref in irq_data_get_affinity_mask()If ipi_send_{mask|single}() is called with an invalid interrupt number, allthe local variables there will be NULL. ipi_send_verify() which is invokedfrom these functions does verify its 'data' parameter, resulting in akernel oops in irq_data_get_affinity_mask() as the passed NULL pointer getsdereferenced.Add a missing NULL pointer check in ipi_send_verify()...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53339 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix BUG_ON condition in btrfs_cancel_balancePausing and canceling balance can race to interrupt balance lead to BUG_ONpanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balancedoes not take this race scenario into account.However, the race condition has no other side effects. We can fix that.Reproducing it with panic trace like this: kernel BUG at fs/btrfs/volumes.c:4618! RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0 Call Trace: ? do_nanosleep+0x60/0x120 ? hrtimer_nanosleep+0xb7/0x1a0 ? sched_core_clone_cookie+0x70/0x70 btrfs_ioctl_balance_ctl+0x55/0x70 btrfs_ioctl+0xa46/0xd20 __x64_sys_ioctl+0x7d/0xa0 do_syscall_64+0x38/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Race scenario as follows: > mutex_unlock(&fs_info->balance_mutex); > -------------------- > .......issue pause and cancel req in another thread > -------------------- > ret = __btrfs_balance(fs_info); > > mutex_lock(&fs_info->balance_mutex); > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) { > btrfs_info(fs_info, "balance: paused"); > btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED); > }

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53343 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp6: Fix null-ptr-deref of ip6_null_entry->rt6i_idev in icmp6_dev().With some IPv6 Ext Hdr (RPL, SRv6, etc.), we can send a packet thathas the link-local address as src and dst IP and will be forwarded toan external IP in the IPv6 Ext Hdr.For example, the script below generates a packet whose src IP is thelink-local address and dst is updated to 11::. # for f in $(find /proc/sys/net/ -name *seg6_enabled*); do echo 1 > $f; done # python3 >>> from socket import * >>> from scapy.all import * >>> >>> SRC_ADDR = DST_ADDR = "fe80::5054:ff:fe12:3456" >>> >>> pkt = IPv6(src=SRC_ADDR, dst=DST_ADDR) >>> pkt /= IPv6ExtHdrSegmentRouting(type=4, addresses=["11::", "22::"], segleft=1) >>> >>> sk = socket(AF_INET6, SOCK_RAW, IPPROTO_RAW) >>> sk.sendto(bytes(pkt), (DST_ADDR, 0))For such a packet, we call ip6_route_input() to look up a route for thenext destination in these three functions depending on the header type. * ipv6_rthdr_rcv() * ipv6_rpl_srh_rcv() * ipv6_srh_rcv()If no route is found, ip6_null_entry is set to skb, and the followingdst_input(skb) calls ip6_pkt_drop().Finally, in icmp6_dev(), we dereference skb_rt6_info(skb)->rt6i_idev->devas the input device is the loopback interface. Then, we have to check ifskb_rt6_info(skb)->rt6i_idev is NULL or not to avoid NULL pointer dereffor ip6_null_entry.BUG: kernel NULL pointer dereference, address: 0000000000000000 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 0 PID: 157 Comm: python3 Not tainted 6.4.0-11996-gb121d614371c #35Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:icmp6_send (net/ipv6/icmp.c:436 net/ipv6/icmp.c:503)Code: fe ff ff 48 c7 40 30 c0 86 5d 83 e8 c6 44 1c 00 e9 c8 fc ff ff 49 8b 46 58 48 83 e0 fe 0f 84 4a fb ff ff 48 8b 80 d0 00 00 00 <48> 8b 00 44 8b 88 e0 00 00 00 e9 34 fb ff ff 4d 85 ed 0f 85 69 01RSP: 0018:ffffc90000003c70 EFLAGS: 00000286RAX: 0000000000000000 RBX: 0000000000000001 RCX: 00000000000000e0RDX: 0000000000000021 RSI: 0000000000000000 RDI: ffff888006d72a18RBP: ffffc90000003d80 R08: 0000000000000000 R09: 0000000000000001R10: ffffc90000003d98 R11: 0000000000000040 R12: ffff888006d72a10R13: 0000000000000000 R14: ffff8880057fb800 R15: ffffffff835d86c0FS: 00007f9dc72ee740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000057b2000 CR4: 00000000007506f0PKRU: 55555554Call Trace: ip6_pkt_drop (net/ipv6/route.c:4513) ipv6_rthdr_rcv (net/ipv6/exthdrs.c:640 net/ipv6/exthdrs.c:686) ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:437 (discriminator 5)) ip6_input_finish (./include/linux/rcupdate.h:781 net/ipv6/ip6_input.c:483) __netif_receive_skb_one_core (net/core/dev.c:5455) process_backlog (./include/linux/rcupdate.h:781 net/core/dev.c:5895) __napi_poll (net/core/dev.c:6460) net_rx_action (net/core/dev.c:6529 net/core/dev.c:6660) __do_softirq (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:207 ./include/trace/events/irq.h:142 kernel/softirq.c:554) do_softirq (kernel/softirq.c:454 kernel/softirq.c:441) __local_bh_enable_ip (kernel/softirq.c:381) __dev_queue_xmit (net/core/dev.c:4231) ip6_finish_output2 (./include/net/neighbour.h:544 net/ipv6/ip6_output.c:135) rawv6_sendmsg (./include/net/dst.h:458 ./include/linux/netfilter.h:303 net/ipv6/raw.c:656 net/ipv6/raw.c:914) sock_sendmsg (net/socket.c:725 net/socket.c:748) __sys_sendto (net/socket.c:2134) __x64_sys_sendto (net/socket.c:2146 net/socket.c:2142 net/socket.c:2142) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)RIP: 0033:0x7f9dc751baeaCode: d8 64 89 02 48 c7 c0 ff f---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kernel/fail_function: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53347 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Handle pairing of E-switch via uplink un/load APIsIn case user switch a device from switchdev mode to legacy mode, mlx5first unpair the E-switch and afterwards unload the uplink vport.From the other hand, in case user remove or reload a device, mlx5first unload the uplink vport and afterwards unpair the E-switch.The latter is causing a bug[1], hence, handle pairing of E-switch aspart of uplink un/load APIs.[1]In case VF_LAG is used, every tc fdb flow is duplicated to the peeresw. However, the original esw keeps a pointer to this duplicatedflow, not the peer esw.e.g.: if user create tc fdb flow over esw0, the flow is duplicatedover esw1, in FW/HW, but in SW, esw0 keeps a pointer to the duplicatedflow.During module unload while a peer tc fdb flow is still offloaded, incase the first device to be removed is the peer device (esw1 in theexample above), the peer net-dev is destroyed, and so the mlx5e_privis memset to 0.Afterwards, the peer device is trying to unpair himself from theoriginal device (esw0 in the example above). Unpair API invoke theoriginal device to clear peer flow from its eswitch (esw0), but thepeer flow, which is stored over the original eswitch (esw0), istrying to use the peer mlx5e_priv, which is memset to 0 and result inbellow kernel-oops.[ 157.964081 ] BUG: unable to handle page fault for address: 000000000002ce60[ 157.964662 ] #PF: supervisor read access in kernel mode[ 157.965123 ] #PF: error_code(0x0000) - not-present page[ 157.965582 ] PGD 0 P4D 0[ 157.965866 ] Oops: 0000 [#1] SMP[ 157.967670 ] RIP: 0010:mlx5e_tc_del_fdb_flow+0x48/0x460 [mlx5_core][ 157.976164 ] Call Trace:[ 157.976437 ] [ 157.976690 ] __mlx5e_tc_del_fdb_peer_flow+0xe6/0x100 [mlx5_core][ 157.977230 ] mlx5e_tc_clean_fdb_peer_flows+0x67/0x90 [mlx5_core][ 157.977767 ] mlx5_esw_offloads_unpair+0x2d/0x1e0 [mlx5_core][ 157.984653 ] mlx5_esw_offloads_devcom_event+0xbf/0x130 [mlx5_core][ 157.985212 ] mlx5_devcom_send_event+0xa3/0xb0 [mlx5_core][ 157.985714 ] esw_offloads_disable+0x5a/0x110 [mlx5_core][ 157.986209 ] mlx5_eswitch_disable_locked+0x152/0x170 [mlx5_core][ 157.986757 ] mlx5_eswitch_disable+0x51/0x80 [mlx5_core][ 157.987248 ] mlx5_unload+0x2a/0xb0 [mlx5_core][ 157.987678 ] mlx5_uninit_one+0x5f/0xd0 [mlx5_core][ 157.988127 ] remove_one+0x64/0xe0 [mlx5_core][ 157.988549 ] pci_device_remove+0x31/0xa0[ 157.988933 ] device_release_driver_internal+0x18f/0x1f0[ 157.989402 ] driver_detach+0x3f/0x80[ 157.989754 ] bus_remove_driver+0x70/0xf0[ 157.990129 ] pci_unregister_driver+0x34/0x90[ 157.990537 ] mlx5_cleanup+0xc/0x1c [mlx5_core][ 157.990972 ] __x64_sys_delete_module+0x15a/0x250[ 157.991398 ] ? exit_to_user_mode_prepare+0xea/0x110[ 157.991840 ] do_syscall_64+0x3d/0x90[ 157.992198 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53348 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when aborting transaction during relocation with scrubBefore relocating a block group we pause scrub, then do the relocation andthen unpause scrub. The relocation process requires starting and committinga transaction, and if we have a failure in the critical section of thetransaction commit path (transaction state >= TRANS_STATE_COMMIT_START),we will deadlock if there is a paused scrub.That results in stack traces like the following: [42.479] BTRFS info (device sdc): relocating block group 53876686848 flags metadata|raid6 [42.936] BTRFS warning (device sdc): Skipping commit of aborted transaction. [42.936] ------------[ cut here ]------------ [42.936] BTRFS: Transaction aborted (error -28) [42.936] WARNING: CPU: 11 PID: 346822 at fs/btrfs/transaction.c:1977 btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Modules linked in: dm_flakey dm_mod loop btrfs (...) [42.936] CPU: 11 PID: 346822 Comm: btrfs Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [42.936] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [42.936] RIP: 0010:btrfs_commit_transaction+0xcc8/0xeb0 [btrfs] [42.936] Code: ff ff 45 8b (...) [42.936] RSP: 0018:ffffb58649633b48 EFLAGS: 00010282 [42.936] RAX: 0000000000000000 RBX: ffff8be6ef4d5bd8 RCX: 0000000000000000 [42.936] RDX: 0000000000000002 RSI: ffffffffb35e7782 RDI: 00000000ffffffff [42.936] RBP: ffff8be6ef4d5c98 R08: 0000000000000000 R09: ffffb586496339e8 [42.936] R10: 0000000000000001 R11: 0000000000000001 R12: ffff8be6d38c7c00 [42.936] R13: 00000000ffffffe4 R14: ffff8be6c268c000 R15: ffff8be6ef4d5cf0 [42.936] FS: 00007f381a82b340(0000) GS:ffff8beddfcc0000(0000) knlGS:0000000000000000 [42.936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [42.936] CR2: 00007f1e35fb7638 CR3: 0000000117680006 CR4: 0000000000370ee0 [42.936] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [42.936] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [42.936] Call Trace: [42.936] [42.936] ? start_transaction+0xcb/0x610 [btrfs] [42.936] prepare_to_relocate+0x111/0x1a0 [btrfs] [42.936] relocate_block_group+0x57/0x5d0 [btrfs] [42.936] ? btrfs_wait_nocow_writers+0x25/0xb0 [btrfs] [42.936] btrfs_relocate_block_group+0x248/0x3c0 [btrfs] [42.936] ? __pfx_autoremove_wake_function+0x10/0x10 [42.936] btrfs_relocate_chunk+0x3b/0x150 [btrfs] [42.936] btrfs_balance+0x8ff/0x11d0 [btrfs] [42.936] ? __kmem_cache_alloc_node+0x14a/0x410 [42.936] btrfs_ioctl+0x2334/0x32c0 [btrfs] [42.937] ? mod_objcg_state+0xd2/0x360 [42.937] ? refill_obj_stock+0xb0/0x160 [42.937] ? seq_release+0x25/0x30 [42.937] ? __rseq_handle_notify_resume+0x3b5/0x4b0 [42.937] ? percpu_counter_add_batch+0x2e/0xa0 [42.937] ? __x64_sys_ioctl+0x88/0xc0 [42.937] __x64_sys_ioctl+0x88/0xc0 [42.937] do_syscall_64+0x38/0x90 [42.937] entry_SYSCALL_64_after_hwframe+0x72/0xdc [42.937] RIP: 0033:0x7f381a6ffe9b [42.937] Code: 00 48 89 44 24 (...) [42.937] RSP: 002b:00007ffd45ecf060 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [42.937] RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007f381a6ffe9b [42.937] RDX: 00007ffd45ecf150 RSI: 00000000c4009420 RDI: 0000000000000003 [42.937] RBP: 0000000000000003 R08: 0000000000000013 R09: 0000000000000000 [42.937] R10: 00007f381a60c878 R11: 0000000000000246 R12: 00007ffd45ed0423 [42.937] R13: 00007ffd45ecf150 R14: 0000000000000000 R15: 00007ffd45ecf148 [42.937] [42.937] ---[ end trace 0000000000000000 ]--- [42.937] BTRFS: error (device sdc: state A) in cleanup_transaction:1977: errno=-28 No space left [59.196] INFO: task btrfs:346772 blocked for more than 120 seconds. [59.196] Tainted: G W 6.3.0-rc2-btrfs-next-127+ #1 [59.196] "echo 0 > /proc/sys/kernel/hung_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53353 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: postpone mem_mgr IDR destruction to hpriv_release()The memory manager IDR is currently destroyed when user releases thefile descriptor.However, at this point the user context might be still held, and memorybuffers might be still in use.Later on, calls to release those buffers will fail due to not findingtheir handles in the IDR, leading to a memory leak.To avoid this leak, split the IDR destruction from the memory managerfini, and postpone it to hpriv_release() when there is no user contextand no buffers are used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:skbuff: skb_segment, Call zero copy functions before using skbuff fragsCommit bf5c25d60861 ("skbuff: in skb_segment, call zerocopy functionsonce per nskb") added the call to zero copy functions in skb_segment().The change introduced a bug in skb_segment() because skb_orphan_frags()may possibly change the number of fragments or allocate new fragmentsaltogether leaving nrfrags and frag to point to the old values. This cancause a panic with stacktrace like the one below.[ 193.894380] BUG: kernel NULL pointer dereference, address: 00000000000000bc[ 193.895273] CPU: 13 PID: 18164 Comm: vh-net-17428 Kdump: loaded Tainted: G O 5.15.123+ #26[ 193.903919] RIP: 0010:skb_segment+0xb0e/0x12f0[ 194.021892] Call Trace:[ 194.027422] [ 194.072861] tcp_gso_segment+0x107/0x540[ 194.082031] inet_gso_segment+0x15c/0x3d0[ 194.090783] skb_mac_gso_segment+0x9f/0x110[ 194.095016] __skb_gso_segment+0xc1/0x190[ 194.103131] netem_enqueue+0x290/0xb10 [sch_netem][ 194.107071] dev_qdisc_enqueue+0x16/0x70[ 194.110884] __dev_queue_xmit+0x63b/0xb30[ 194.121670] bond_start_xmit+0x159/0x380 [bonding][ 194.128506] dev_hard_start_xmit+0xc3/0x1e0[ 194.131787] __dev_queue_xmit+0x8a0/0xb30[ 194.138225] macvlan_start_xmit+0x4f/0x100 [macvlan][ 194.141477] dev_hard_start_xmit+0xc3/0x1e0[ 194.144622] sch_direct_xmit+0xe3/0x280[ 194.147748] __dev_queue_xmit+0x54a/0xb30[ 194.154131] tap_get_user+0x2a8/0x9c0 [tap][ 194.157358] tap_sendmsg+0x52/0x8e0 [tap][ 194.167049] handle_tx_zerocopy+0x14e/0x4c0 [vhost_net][ 194.173631] handle_tx+0xcd/0xe0 [vhost_net][ 194.176959] vhost_worker+0x76/0xb0 [vhost][ 194.183667] kthread+0x118/0x140[ 194.190358] ret_from_fork+0x1f/0x30[ 194.193670] In this case calling skb_orphan_frags() updated nr_frags leaving nrfragslocal variable in skb_segment() stale. This resulted in the code hittingi >= nrfrags prematurely and trying to move to next frag_skb usinglist_skb pointer, which was NULL, and caused kernel panic. Move the callto zero copy functions before using frags and nr_frags.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53355 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: pi433: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once. This requires saving off the root directory dentry to makecreation of individual device subdirectories easier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53365 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip6mr: Fix skb_under_panic in ip6mr_cache_report()skbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4 head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:192! invalid opcode: 0000 [#1] PREEMPT SMP KASAN CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: ipv6_addrconf addrconf_dad_work RIP: 0010:skb_panic+0x152/0x1d0 Call Trace: skb_push+0xc4/0xe0 ip6mr_cache_report+0xd69/0x19b0 reg_vif_xmit+0x406/0x690 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 vlan_dev_hard_start_xmit+0x3ab/0x5c0 dev_hard_start_xmit+0x17e/0x6e0 __dev_queue_xmit+0x2d6a/0x3d20 neigh_connected_output+0x3ed/0x570 ip6_finish_output2+0x5b5/0x1950 ip6_finish_output+0x693/0x11c0 ip6_output+0x24b/0x880 NF_HOOK.constprop.0+0xfd/0x530 ndisc_send_skb+0x9db/0x1400 ndisc_send_rs+0x12a/0x6c0 addrconf_dad_completed+0x3c9/0xea0 addrconf_dad_work+0x849/0x1420 process_one_work+0xa22/0x16e0 worker_thread+0x679/0x10c0 ret_from_fork+0x28/0x60 ret_from_fork_asm+0x11/0x20When setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().reg_vif_xmit() ip6mr_cache_report() skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4And skb_push declared as: void *skb_push(struct sk_buff *skb, unsigned int len); skb->data -= len; //0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850skb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53367 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: fix mem leak in capture user mappingsThis commit fixes a memory leak caused when clearing the user_mappingsinfo when a new context is opened immediately after user_mapping iscaptured and a hard reset is performed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dcb: choose correct policy to parse DCB_ATTR_BCNThe dcbnl_bcn_setcfg uses erroneous policy to parse tb[DCB_ATTR_BCN],which is introduced in commit 859ee3c43812 ("DCB: Add support for DCBBCN"). Please see the comment in below codestatic int dcbnl_bcn_setcfg(...){ ... ret = nla_parse_nested_deprecated(..., dcbnl_pfc_up_nest, .. ) // !!! dcbnl_pfc_up_nest for attributes // DCB_PFC_UP_ATTR_0 to DCB_PFC_UP_ATTR_ALL in enum dcbnl_pfc_up_attrs ... for (i = DCB_BCN_ATTR_RP_0; i <= DCB_BCN_ATTR_RP_7; i++) { // !!! DCB_BCN_ATTR_RP_0 to DCB_BCN_ATTR_RP_7 in enum dcbnl_bcn_attrs ... value_byte = nla_get_u8(data[i]); ... } ... for (i = DCB_BCN_ATTR_BCNA_0; i <= DCB_BCN_ATTR_RI; i++) { // !!! DCB_BCN_ATTR_BCNA_0 to DCB_BCN_ATTR_RI in enum dcbnl_bcn_attrs ... value_int = nla_get_u32(data[i]); ... } ...}That is, the nla_parse_nested_deprecated uses dcbnl_pfc_up_nestattributes to parse nlattr defined in dcbnl_pfc_up_attrs. But thefollowing access code fetch each nlattr as dcbnl_bcn_attrs attributes.By looking up the associated nla_policy for dcbnl_bcn_attrs. We can findthe beginning part of these two policies are "same".static const struct nla_policy dcbnl_pfc_up_nest[...] = { [DCB_PFC_UP_ATTR_0] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_1] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_2] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_3] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_4] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_5] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_6] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_7] = {.type = NLA_U8}, [DCB_PFC_UP_ATTR_ALL] = {.type = NLA_FLAG},};static const struct nla_policy dcbnl_bcn_nest[...] = { [DCB_BCN_ATTR_RP_0] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_1] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_2] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_3] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_4] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_5] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_6] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_7] = {.type = NLA_U8}, [DCB_BCN_ATTR_RP_ALL] = {.type = NLA_FLAG}, // from here is somewhat different [DCB_BCN_ATTR_BCNA_0] = {.type = NLA_U32}, ... [DCB_BCN_ATTR_ALL] = {.type = NLA_FLAG},};Therefore, the current code is buggy and thisnla_parse_nested_deprecated could overflow the dcbnl_pfc_up_nest and usethe adjacent nla_policy to parse attributes from DCB_BCN_ATTR_BCNA_0.Hence use the correct policy dcbnl_bcn_nest to parse the nestedtb[DCB_ATTR_BCN] TLV.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53371 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix memory leak in mlx5e_fs_tt_redirect_any_createThe memory pointed to by the fs->any pointer is not freed in the errorpath of mlx5e_fs_tt_redirect_any_create, which can lead to a memory leak.Fix by freeing the memory in the error path, thereby making the error pathidentical to mlx5e_fs_tt_redirect_any_destroy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: fix a potential overflow in sctp_ifwdtsn_skipCurrently, when traversing ifwdtsn skips with _sctp_walk_ifwdtsn, it onlychecks the pos against the end of the chunk. However, the data left forthe last pos may be < sizeof(struct sctp_ifwdtsn_skip), and dereferenceit as struct sctp_ifwdtsn_skip may cause coverflow.This patch fixes it by checking the pos against "the end of the chunk -sizeof(struct sctp_ifwdtsn_skip)" in sctp_ifwdtsn_skip, similar tosctp_fwdtsn_skip.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53376 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Use number of bits to manage bitmap sizesTo allocate bitmaps, the mpi3mr driver calculates sizes of bitmaps usingbyte as unit. However, bitmap helper functions assume that bitmaps areallocated using unsigned long as unit. This gap causes memory access beyondthe bitmap sizes and results in "BUG: KASAN: slab-out-of-bounds". The BUGwas observed at firmware download to eHBA-9600. Call trace indicated thatthe out-of-bounds access happened in find_first_zero_bit() called frommpi3mr_send_event_ack() for miroc->evtack_cmds_bitmap.To fix the BUG, do not use bytes to manage bitmap sizes. Instead, usenumber of bits, and call bitmap helper functions which take number of bitsas arguments. For memory allocation, call bitmap_zalloc() instead ofkzalloc() and krealloc(). For memory free, call bitmap_free() instead ofkfree(). For zero clear, call bitmap_clear() instead of memset().Remove three fields for bitmap byte sizes in struct scmd_priv which are nolonger required. Replace the field dev_handle_bitmap_sz withdev_handle_bitmap_bits to keep number of bits of removepend_bitmap acrossresize.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53382 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: Reset connection when trying to use SMCRv2 fails.We found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. Itcan be reproduced by:- smc_run nginx- smc_run wrk -t 32 -c 500 -d 30 http://: BUG: kernel NULL pointer dereference, address: 0000000000000014 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G W E 6.4.0-rc1+ #42 Workqueue: smc_hs_wq smc_listen_work [smc] RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc] RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06 RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000 RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00 RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000 R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180 R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib] ? smcr_buf_map_link+0x24b/0x290 [smc] ? __smc_buf_create+0x4ee/0x9b0 [smc] smc_clc_send_accept+0x4c/0xb0 [smc] smc_listen_work+0x346/0x650 [smc] ? __schedule+0x279/0x820 process_one_work+0x1e5/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 During the CLC handshake, server sequentially tries available SMCRv2and SMCRv1 devices in smc_listen_work().If an SMCRv2 device is found. SMCv2 based link group and link will beassigned to the connection. Then assumed that some buffer assignmenterrors happen later in the CLC handshake, such as RMB registrationfailure, server will give up SMCRv2 and try SMCRv1 device instead. Butthe resources assigned to the connection won't be reset.When server tries SMCRv1 device, the connection creation process willbe executed again. Since conn->lnk has been assigned when trying SMCRv2,it will not be set to the correct SMCRv1 link insmcr_lgr_conn_assign_link(). So in such situation, conn->lgr points tocorrect SMCRv1 link group but conn->lnk points to the SMCRv2 linkmistakenly.Then in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]will be accessed. Since the link->link_idx is not correct, the relatedMR may not have been initialized, so crash happens. | Try SMCRv2 device first | |-> conn->lgr: assign existed SMCRv2 link group; | |-> conn->link: assign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC); | |-> sndbuf & RMB creation fails, quit; | | Try SMCRv1 device then | |-> conn->lgr: create SMCRv1 link group and assign; | |-> conn->link: keep SMCRv2 link mistakenly; | |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0] | initialized. | | Then smc_clc_send_confirm_accept() accesses | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash. vThis patch tries to fix this by cleaning conn->lnk before assigninglink. In addition, it is better to reset the connection and clean theresources assigned if trying SMCRv2 failed in buffer creation orregistration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53383 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4The T241 platform suffers from the T241-FABRIC-4 erratum which causesunexpected behavior in the GIC when multiple transactions are receivedsimultaneously from different sources. This hardware issue impactsNVIDIA server platforms that use more than two T241 chipsinterconnected. Each chip has support for 320 {E}SPIs.This issue occurs when multiple packets from different GICs areincorrectly interleaved at the target chip. The erratum text belowspecifies exactly what can cause multiple transfer packets susceptibleto interleaving and GIC state corruption. GIC state corruption canlead to a range of problems, including kernel panics, and unexpectedbehavior.>From the erratum text: "In some cases, inter-socket AXI4 Stream packets with multiple transfers, may be interleaved by the fabric when presented to ARM Generic Interrupt Controller. GIC expects all transfers of a packet to be delivered without any interleaving. The following GICv3 commands may result in multiple transfer packets over inter-socket AXI4 Stream interface: - Register reads from GICD_I* and GICD_N* - Register writes to 64-bit GICD registers other than GICD_IROUTERn* - ITS command MOVALL Multiple commands in GICv4+ utilize multiple transfer packets, including VMOVP, VMOVI, VMAPP, and 64-bit register accesses." This issue impacts system configurations with more than 2 sockets, that require multi-transfer packets to be sent over inter-socket AXI4 Stream interface between GIC instances on different sockets. GICv4 cannot be supported. GICv3 SW model can only be supported with the workaround. Single and Dual socket configurations are not impacted by this issue and support GICv3 and GICv4."Writing to the chip alias region of the GICD_In{E} registers exceptGICD_ICENABLERn has an equivalent effect as writing to the globaldistributor. The SPI interrupt deactivate path is not impacted bythe erratum.To fix this problem, implement a workaround that ensures read accessesto the GICD_In{E} registers are directed to the chip that owns theSPI, and disable GICv4.x features. To simplify code changes, thegic_configure_irq() function uses the same alias region for both readand write operations to GICD_ICFGR.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53387 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix device management cmd timeout flowIn the UFS error handling flow, the host will send a device management cmd(NOP OUT) to the device for link recovery. If this cmd times out andclearing the doorbell fails, ufshcd_wait_for_dev_cmd() will do nothing andreturn. hba->dev_cmd.complete struct is not set to NULL.When this happens, if cmd has been completed by device, then we will callcomplete() in __ufshcd_transfer_req_compl(). Because the complete struct isallocated on the stack, the following crash will occur: ipanic_die+0x24/0x38 [mrdump] die+0x344/0x748 arm64_notify_die+0x44/0x104 do_debug_exception+0x104/0x1e0 el1_dbg+0x38/0x54 el1_sync_handler+0x40/0x88 el1_sync+0x8c/0x140 queued_spin_lock_slowpath+0x2e4/0x3c0 __ufshcd_transfer_req_compl+0x3b0/0x1164 ufshcd_trc_handler+0x15c/0x308 ufshcd_host_reset_and_restore+0x54/0x260 ufshcd_reset_and_restore+0x28c/0x57c ufshcd_err_handler+0xeb8/0x1b6c process_one_work+0x288/0x964 worker_thread+0x4bc/0xc7c kthread+0x15c/0x264 ret_from_fork+0x10/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53391 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:shmem: use ramfs_kill_sb() for kill_sb method of ramfs-based tmpfsAs the ramfs-based tmpfs uses ramfs_init_fs_context() for theinit_fs_context method, which allocates fc->s_fs_info, use ramfs_kill_sb()to free it and avoid a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53397 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:modpost: fix off by one in is_executable_section()The > comparison should be >= to prevent an out of bounds arrayaccess.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53401 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()KCSAN found an issue in obj_stock_flush_required():stock->cached_objcg can be reset between the check and dereference:==================================================================BUG: KCSAN: data-race in drain_all_stock / drain_obj_stockwrite to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0: drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306 refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340 obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408 memcg_slab_free_hook mm/slab.h:587 [inline] __cache_free mm/slab.c:3373 [inline] __do_kmem_cache_free mm/slab.c:3577 [inline] kmem_cache_free+0x105/0x280 mm/slab.c:3602 __d_free fs/dcache.c:298 [inline] dentry_free fs/dcache.c:375 [inline] __dentry_kill+0x422/0x4a0 fs/dcache.c:621 dentry_kill+0x8d/0x1e0 dput+0x118/0x1f0 fs/dcache.c:913 __fput+0x3bf/0x570 fs/file_table.c:329 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x123/0x160 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171 exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296 do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1: obj_stock_flush_required mm/memcontrol.c:3319 [inline] drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361 try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703 try_charge mm/memcontrol.c:2837 [inline] mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290 sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025 sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525 udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692 udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817 sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668 __sys_setsockopt+0x1c3/0x230 net/socket.c:2271 __do_sys_setsockopt net/socket.c:2282 [inline] __se_sys_setsockopt net/socket.c:2279 [inline] __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0xffff8881382d52c0 -> 0xffff888138893740Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023Fix it by using READ_ONCE()/WRITE_ONCE() for all accesses tostock->cached_objcg.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53408 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:trace/blktrace: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53411 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM: EM: fix memory leak with using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. To make things simpler, justcall debugfs_lookup_and_remove() instead which handles all of the logicat once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53419 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect rcu_print_task_exp_stall() ->exp_tasks accessFor kernels built with CONFIG_PREEMPT_RCU=y, the following scenario canresult in a NULL-pointer dereference: CPU1 CPU2rcu_preempt_deferred_qs_irqrestore rcu_print_task_exp_stall if (special.b.blocked) READ_ONCE(rnp->exp_tasks) != NULL raw_spin_lock_rcu_node np = rcu_next_node_entry(t, rnp) if (&t->rcu_node_entry == rnp->exp_tasks) WRITE_ONCE(rnp->exp_tasks, np) .... raw_spin_unlock_irqrestore_rcu_node raw_spin_lock_irqsave_rcu_node t = list_entry(rnp->exp_tasks->prev, struct task_struct, rcu_node_entry) (if rnp->exp_tasks is NULL, this will dereference a NULL pointer)The problem is that CPU2 accesses the rcu_node structure's->exp_tasksfield without holding the rcu_node structure's ->lock and CPU2 didnot observe CPU1's change to rcu_node structure's ->exp_tasks in time.Therefore, if CPU1 sets rcu_node structure's->exp_tasks pointer to NULL,then CPU2 might dereference that NULL pointer.This commit therefore holds the rcu_node structure's ->lock whileaccessing that structure's->exp_tasks field.[ paulmck: Apply Frederic Weisbecker feedback. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53421 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Reinit blkg_iostat_set after clearing in blkcg_reset_stats()When blkg_alloc() is called to allocate a blkcg_gq structurewith the associated blkg_iostat_set's, there are 2 fields withinblkg_iostat_set that requires proper initialization - blkg & sync.The former field was introduced by commit 3b8cc6298724 ("blk-cgroup:Optimize blkcg_rstat_flush()") while the later one was introduced bycommit f73316482977 ("blk-cgroup: reimplement basic IO stats usingcgroup rstat").Unfortunately those fields in the blkg_iostat_set's are not properlyre-initialized when they are cleared in v1's blkcg_reset_stats(). Thiscan lead to a kernel panic due to NULL pointer access of the blkgpointer. The missing initialization of sync is less problematic andcan be a problem in a debug kernel due to missing lockdep initialization.Fix these problems by re-initializing them after memory clearing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53423 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:objtool: Fix memory leak in create_static_call_sections()strdup() allocates memory for key_name. We need to release the memory inthe following error paths. Add free() to avoid memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53425 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: mediatek: vpu: fix NULL ptr dereferenceIf pdev is NULL, then it is still dereferenced.This fixes this smatch warning:drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53429 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't check PageError in __extent_writepage__extent_writepage currenly sets PageError whenever any error happens,and the also checks for PageError to decide if to call error handling.This leads to very unclear responsibility for cleaning up on errors.In the VM and generic writeback helpers the basic idea is that onceI/O is fired off all error handling responsibility is delegated to theend I/O handler. But if that end I/O handler sets the PageError bit,and the submitter checks it, the bit could in some cases leak into thesubmission context for fast enough I/O.Fix this by simply not checking PageError and just using the localret variable to check for submission errors. This also fundamentallysolves the long problem documented in a comment in __extent_writepageby never leaking the error bit into the submission context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53433 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: add vlan_get_protocol_and_depth() helperBefore blamed commit, pskb_may_pull() was used insteadof skb_header_pointer() in __vlan_get_protocol() and friends.Few callers depended on skb->head being populated with MAC header,syzbot caught one of them (skb_mac_gso_segment())Add vlan_get_protocol_and_depth() to make the intent clearerand use it where sensible.This is a more generic fix than commit e9d3f80935b6("net/af_packet: make sure to pull mac header") which wasdealing with a similar issue.kernel BUG at include/linux/skbuff.h:2655 !invalid opcode: 0000 [#1] SMP KASANCPU: 0 PID: 1441 Comm: syz-executor199 Not tainted 6.1.24-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023RIP: 0010:__skb_pull include/linux/skbuff.h:2655 [inline]RIP: 0010:skb_mac_gso_segment+0x68f/0x6a0 net/core/gro.c:136Code: fd 48 8b 5c 24 10 44 89 6b 70 48 c7 c7 c0 ae 0d 86 44 89 e6 e8 a1 91 d0 00 48 c7 c7 00 af 0d 86 48 89 de 31 d2 e8 d1 4a e9 ff <0f> 0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41RSP: 0018:ffffc90001bd7520 EFLAGS: 00010286RAX: ffffffff8469736a RBX: ffff88810f31dac0 RCX: ffff888115a18b00RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc90001bd75e8 R08: ffffffff84697183 R09: fffff5200037adf9R10: 0000000000000000 R11: dffffc0000000001 R12: 0000000000000012R13: 000000000000fee5 R14: 0000000000005865 R15: 000000000000fed7FS: 000055555633f300(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 0000000116fea000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] __skb_gso_segment+0x32d/0x4c0 net/core/dev.c:3419[] skb_gso_segment include/linux/netdevice.h:4819 [inline][] validate_xmit_skb+0x3aa/0xee0 net/core/dev.c:3725[] __dev_queue_xmit+0x1332/0x3300 net/core/dev.c:4313[] dev_queue_xmit+0x17/0x20 include/linux/netdevice.h:3029[] packet_snd net/packet/af_packet.c:3111 [inline][] packet_sendmsg+0x49d2/0x6470 net/packet/af_packet.c:3142[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53441 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: cpumap: Fix memory leak in cpu_map_update_elemSyzkaller reported a memory leak as follows:BUG: memory leakunreferenced object 0xff110001198ef748 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 4a 19 00 00 80 ad e3 e4 fe ff c0 00 ....J........... 00 b2 d3 0c 01 00 11 ff 28 f5 8e 19 01 00 11 ff ........(....... backtrace: [] __cpu_map_entry_alloc+0xf7/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff110001198ef528 (size 192): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __cpu_map_entry_alloc+0x260/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6BUG: memory leakunreferenced object 0xff1100010fd93d68 (size 8): comm "syz-executor.3", pid 17672, jiffies 4298118891 (age 9.906s) hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace: [] kvmalloc_node+0x11e/0x170 [] __cpu_map_entry_alloc+0x2f0/0xb00 [] cpu_map_update_elem+0x2fe/0x3d0 [] bpf_map_update_value.isra.0+0x2bd/0x520 [] map_update_elem+0x4cb/0x720 [] __se_sys_bpf+0x8c3/0xb90 [] do_syscall_64+0x30/0x40 [] entry_SYSCALL_64_after_hwframe+0x61/0xc6In the cpu_map_update_elem flow, when kthread_stop is called beforecalling the threadfn of rcpu->kthread, since the KTHREAD_SHOULD_STOP bitof kthread has been set by kthread_stop, the threadfn of rcpu->kthreadwill never be executed, and rcpu->refcnt will never be 0, which willlead to the allocated rcpu, rcpu->queue and rcpu->queue->queue cannot bereleased.Calling kthread_stop before executing kthread's threadfn will return-EINTR. We can complete the release of memory resources in this state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53445 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Fix a refcount bug in qrtr_recvmsg()Syzbot reported a bug as following:refcount_t: addition on 0; use-after-free....RIP: 0010:refcount_warn_saturate+0x17c/0x1f0 lib/refcount.c:25...Call Trace: __refcount_add include/linux/refcount.h:199 [inline] __refcount_inc include/linux/refcount.h:250 [inline] refcount_inc include/linux/refcount.h:267 [inline] kref_get include/linux/kref.h:45 [inline] qrtr_node_acquire net/qrtr/af_qrtr.c:202 [inline] qrtr_node_lookup net/qrtr/af_qrtr.c:398 [inline] qrtr_send_resume_tx net/qrtr/af_qrtr.c:1003 [inline] qrtr_recvmsg+0x85f/0x990 net/qrtr/af_qrtr.c:1070 sock_recvmsg_nosec net/socket.c:1017 [inline] sock_recvmsg+0xe2/0x160 net/socket.c:1038 qrtr_ns_worker+0x170/0x1700 net/qrtr/ns.c:688 process_one_work+0x991/0x15c0 kernel/workqueue.c:2390 worker_thread+0x669/0x1090 kernel/workqueue.c:2537It occurs in the concurrent scenario of qrtr_recvmsg() andqrtr_endpoint_unregister() as following: cpu0 cpu1qrtr_recvmsg qrtr_endpoint_unregisterqrtr_send_resume_tx qrtr_node_releaseqrtr_node_lookup mutex_lock(&qrtr_node_lock)spin_lock_irqsave(&qrtr_nodes_lock, ) refcount_dec_and_test(&node->ref) [node->ref == 0]radix_tree_lookup [node != NULL] __qrtr_node_releaseqrtr_node_acquire spin_lock_irqsave(&qrtr_nodes_lock, )kref_get(&node->ref) [WARNING] ... mutex_unlock(&qrtr_node_lock)Use qrtr_node_lock to protect qrtr_node_lookup() implementation, thisis actually improving the protection of node reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53450 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: remove a BUG_ON in ext4_mb_release_group_pa()If a malicious fuzzer overwrites the ext4 superblock while it ismounted such that the s_first_data_block is set to a very largenumber, the calculation of the block group can underflow, and triggera BUG_ON check. Change this to be an ext4_warning so that we don'tcrash the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53460 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: fix memory leak in rtw_usb_probe()drivers/net/wireless/realtek/rtw88/usb.c:876 rtw_usb_probe()warn: 'hw' from ieee80211_alloc_hw() not released on lines: 811Fix this by modifying return to a goto statement.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53461 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: wait interruptibly for request completions on exitWHen the ring exits, cleanup is done and the final cancelation andwaiting on completions is done by io_ring_exit_work. That function isinvoked by kworker, which doesn't take any signals. Because of that, itdoesn't really matter if we wait for completions in TASK_INTERRUPTIBLEor TASK_UNINTERRUPTIBLE state. However, it does matter to the hung taskdetection checker!Normally we expect cancelations and completions to happen ratherquickly. Some test cases, however, will exit the ring and park theowning task stopped (eg via SIGSTOP). If the owning task needs to runtask_work to complete requests, then io_ring_exit_work won't make anyprogress until the task is runnable again. Hence io_ring_exit_work cantrigger the hung task detection, which is particularly problematic ifpanic-on-hung-task is enabled.As the ring exit doesn't take signals to begin with, have it waitinterruptibly rather than uninterruptibly. io_uring has a separatestuck-exit warning that triggers independently anyway, so we're notreally missing anything by making this switch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53466 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7915: fix memory leak in mt7915_mcu_exitAlways purge mcu skb queues in mt7915_mcu_exit routine even ifmt7915_firmware_state fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53470 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: catch failure from devlink_allocAdd a check for NULL on the alloc return. If devlink_alloc() fails andwe try to use devlink_priv() on the NULL return, the kernel gets veryunhappy and panics. With this fix, the driver load will still fail,but at least it won't panic the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53477 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Add lwtunnel encap size of all siblings in nexthop calculationIn function rt6_nlmsg_size(), the length of nexthop is calculatedby multipling the nexthop length of fib6_info and the number ofsiblings. However if the fib6_info has no lwtunnel but the siblingshave lwtunnels, the nexthop length is less than it should be, andit will trigger a warning in inet6_rt_notify() as follows:WARNING: CPU: 0 PID: 6082 at net/ipv6/route.c:6180 inet6_rt_notify+0x120/0x130......Call Trace: fib6_add_rt2node+0x685/0xa30 fib6_add+0x96/0x1b0 ip6_route_add+0x50/0xd0 inet6_rtm_newroute+0x97/0xa0 rtnetlink_rcv_msg+0x156/0x3d0 netlink_rcv_skb+0x5a/0x110 netlink_unicast+0x246/0x350 netlink_sendmsg+0x250/0x4c0 sock_sendmsg+0x66/0x70 ___sys_sendmsg+0x7c/0xd0 __sys_sendmsg+0x5d/0xb0 do_syscall_64+0x3f/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcThis bug can be reproduced by script:ip -6 addr add 2002::2/64 dev ens2ip -6 route add 100::/64 via 2002::1 dev ens2 metric 100for i in 10 20 30 40 50 60 70;do ip link add link ens2 name ipv_$i type ipvlan ip -6 addr add 2002::$i/64 dev ipv_$i ifconfig ipv_$i updonefor i in 10 20 30 40 50 60;do ip -6 route append 100::/64 encap ip6 dst 2002::$i via 2002::1dev ipv_$i metric 100doneip -6 route append 100::/64 via 2002::1 dev ipv_70 metric 100This patch fixes it by adding nexthop_len of every siblings usingrt6_nh_nlmsg_size().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53480 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kobject: Add sanity check for kset->kobj.ktype in kset_register()When I register a kset in the following way: static struct kset my_kset; kobject_set_name(&my_kset.kobj, "my_kset"); ret = kset_register(&my_kset);A null pointer dereference exception is occurred:[ 4453.568337] Unable to handle kernel NULL pointer dereference at \virtual address 0000000000000028... ...[ 4453.810361] Call trace:[ 4453.813062] kobject_get_ownership+0xc/0x34[ 4453.817493] kobject_add_internal+0x98/0x274[ 4453.822005] kset_register+0x5c/0xb4[ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]... ...Because I didn't initialize my_kset.kobj.ktype.According to the description in Documentation/core-api/kobject.rst: - A ktype is the type of object that embeds a kobject. Every structure that embeds a kobject needs a corresponding ktype.So add sanity check to make sure kset->kobj.ktype is not NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53482 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu: Fix error unwind in iommu_group_alloc()If either iommu_group_grate_file() fails then theiommu_group is leaked.Destroy it on these error paths.Found by kselftest/iommu/iommufd_fail_nth

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53489 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp/udp: Fix memleaks of sk and zerocopy skbs with TX timestamp.syzkaller reported [0] memory leaks of an UDP socket and ZEROCOPYskbs. We can reproduce the problem with these sequences: sk = socket(AF_INET, SOCK_DGRAM, 0) sk.setsockopt(SOL_SOCKET, SO_TIMESTAMPING, SOF_TIMESTAMPING_TX_SOFTWARE) sk.setsockopt(SOL_SOCKET, SO_ZEROCOPY, 1) sk.sendto(b'', MSG_ZEROCOPY, ('127.0.0.1', 53)) sk.close()sendmsg() calls msg_zerocopy_alloc(), which allocates a skb, setsskb->cb->ubuf.refcnt to 1, and calls sock_hold(). Here, structubuf_info_msgzc indirectly holds a refcnt of the socket. When theskb is sent, __skb_tstamp_tx() clones it and puts the clone intothe socket's error queue with the TX timestamp.When the original skb is received locally, skb_copy_ubufs() callsskb_unclone(), and pskb_expand_head() increments skb->cb->ubuf.refcnt.This additional count is decremented while freeing the skb, but structubuf_info_msgzc still has a refcnt, so __msg_zerocopy_callback() isnot called.The last refcnt is not released unless we retrieve the TX timestampedskb by recvmsg(). Since we clear the error queue in inet_sock_destruct()after the socket's refcnt reaches 0, there is a circular dependency.If we close() the socket holding such skbs, we never call sock_put()and leak the count, sk, and skb.TCP has the same problem, and commit e0c8bccd40fc ("net: stream:purge sk_error_queue in sk_stream_kill_queues()") tried to fix itby calling skb_queue_purge() during close(). However, there is asmall chance that skb queued in a qdisc or device could be putinto the error queue after the skb_queue_purge() call.In __skb_tstamp_tx(), the cloned skb should not have a referenceto the ubuf to remove the circular dependency, but skb_clone() doesnot call skb_copy_ubufs() for zerocopy skb. So, we need to callskb_orphan_frags_rx() for the cloned skb to call skb_copy_ubufs().[0]:BUG: memory leakunreferenced object 0xffff88800c6d2d00 (size 1152): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 cd af e8 81 00 00 00 00 ................ 02 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<0000000055636812>] sk_prot_alloc+0x64/0x2a0 net/core/sock.c:2024 [<0000000054d77b7a>] sk_alloc+0x3b/0x800 net/core/sock.c:2083 [<0000000066f3c7e0>] inet_create net/ipv4/af_inet.c:319 [inline] [<0000000066f3c7e0>] inet_create+0x31e/0xe40 net/ipv4/af_inet.c:245 [<000000009b83af97>] __sock_create+0x2ab/0x550 net/socket.c:1515 [<00000000b9b11231>] sock_create net/socket.c:1566 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1603 [inline] [<00000000b9b11231>] __sys_socket_create net/socket.c:1588 [inline] [<00000000b9b11231>] __sys_socket+0x138/0x250 net/socket.c:1636 [<000000004fb45142>] __do_sys_socket net/socket.c:1649 [inline] [<000000004fb45142>] __se_sys_socket net/socket.c:1647 [inline] [<000000004fb45142>] __x64_sys_socket+0x73/0xb0 net/socket.c:1647 [<0000000066999e0e>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<0000000066999e0e>] do_syscall_64+0x38/0x90 arch/x86/entry/common.c:80 [<0000000017f238c1>] entry_SYSCALL_64_after_hwframe+0x63/0xcdBUG: memory leakunreferenced object 0xffff888017633a00 (size 240): comm "syz-executor392", pid 264, jiffies 4294785440 (age 13.044s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 2d 6d 0c 80 88 ff ff .........-m..... backtrace: [<000000002b1c4368>] __alloc_skb+0x229/0x320 net/core/skbuff.c:497 [<00000000143579a6>] alloc_skb include/linux/skbuff.h:1265 [inline] [<00000000143579a6>] sock_omalloc+0xaa/0x190 net/core/sock.c:2596 [<00000000be626478>] msg_zerocopy_alloc net/core/skbuff.c:1294 [inline] [<00000000be626478>]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53495 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mvpp2_main: fix possible OOB write in mvpp2_ethtool_get_rxnfc()rules is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrules to avoid OOB writing or NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53500 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix slab-use-after-free in decode_session6When the xfrm device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when the xfrm device sends IPv6 packets.The stack information is as follows:BUG: KASAN: slab-use-after-free in decode_session6+0x103f/0x1890Read of size 1 at addr ffff8881111458ef by task swapper/3/0CPU: 3 PID: 0 Comm: swapper/3 Not tainted 6.4.0-next-20230707 #409Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014Call Trace:dump_stack_lvl+0xd9/0x150print_address_description.constprop.0+0x2c/0x3c0kasan_report+0x11d/0x130decode_session6+0x103f/0x1890__xfrm_decode_session+0x54/0xb0xfrmi_xmit+0x173/0x1ca0dev_hard_start_xmit+0x187/0x700sch_direct_xmit+0x1a3/0xc30__qdisc_run+0x510/0x17a0__dev_queue_xmit+0x2215/0x3b10neigh_connected_output+0x3c2/0x550ip6_finish_output2+0x55a/0x1550ip6_finish_output+0x6b9/0x1270ip6_output+0x1f1/0x540ndisc_send_skb+0xa63/0x1890ndisc_send_rs+0x132/0x6f0addrconf_rs_timer+0x3f1/0x870call_timer_fn+0x1a0/0x580expire_timers+0x29b/0x4b0run_timer_softirq+0x326/0x910__do_softirq+0x1d4/0x905irq_exit_rcu+0xb7/0x120sysvec_apic_timer_interrupt+0x97/0xc0asm_sysvec_apic_timer_interrupt+0x1a/0x20RIP: 0010:intel_idle_hlt+0x23/0x30Code: 1f 84 00 00 00 00 00 f3 0f 1e fa 41 54 41 89 d4 0f 1f 44 00 00 66 90 0f 1f 44 00 00 0f 00 2d c4 9f ab 00 0f 1f 44 00 00 fb f4 44 89 e0 41 5c c3 66 0f 1f 44 00 00 f3 0f 1e fa 41 54 41 89 d4RSP: 0018:ffffc90000197d78 EFLAGS: 00000246RAX: 00000000000a83c3 RBX: ffffe8ffffd09c50 RCX: ffffffff8a22d8e5RDX: 0000000000000001 RSI: ffffffff8d3f8080 RDI: ffffe8ffffd09c50RBP: ffffffff8d3f8080 R08: 0000000000000001 R09: ffffed1026ba6d9dR10: ffff888135d36ceb R11: 0000000000000001 R12: 0000000000000001R13: ffffffff8d3f8100 R14: 0000000000000001 R15: 0000000000000000cpuidle_enter_state+0xd3/0x6f0cpuidle_enter+0x4e/0xa0do_idle+0x2fe/0x3c0cpu_startup_entry+0x18/0x20start_secondary+0x200/0x290secondary_startup_64_no_verify+0x167/0x16bAllocated by task 939:kasan_save_stack+0x22/0x40kasan_set_track+0x25/0x30__kasan_slab_alloc+0x7f/0x90kmem_cache_alloc_node+0x1cd/0x410kmalloc_reserve+0x165/0x270__alloc_skb+0x129/0x330inet6_ifa_notify+0x118/0x230__ipv6_ifa_notify+0x177/0xbe0addrconf_dad_completed+0x133/0xe00addrconf_dad_work+0x764/0x1390process_one_work+0xa32/0x16f0worker_thread+0x67d/0x10c0kthread+0x344/0x440ret_from_fork+0x1f/0x30The buggy address belongs to the object at ffff888111145800which belongs to the cache skbuff_small_head of size 640The buggy address is located 239 bytes inside offreed 640-byte region [ffff888111145800, ffff888111145a80)As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53501 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd/iommu_v2: Fix pasid_state refcount dec hit 0 warning on pasid unbindWhen unbinding pasid - a race condition exists vs outstanding page faults.To prevent this, the pasid_state object contains a refcount. * set to 1 on pasid bind * incremented on each ppr notification start * decremented on each ppr notification done * decremented on pasid unbindSince refcount_dec assumes that refcount will never reach 0: the current implementation causes the following to be invoked on pasid unbind: REFCOUNT_WARN("decrement hit 0; leaking memory")Fix this issue by changing refcount_dec to refcount_dec_and_testto explicitly handle refcount=1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53533 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: raspberrypi-ts - fix refcount leak in rpi_ts_proberpi_firmware_get() take reference, we need to release it in error pathsas well. Use devm_rpi_firmware_get() helper to handling the resources.Also remove the existing rpi_firmware_put().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53534 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: mtk_drm_crtc: Add checks for devm_kcallocAs the devm_kcalloc may return NULL, the return value needs to be checkedto avoid NULL poineter dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53542 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: dts: exynos: Use Exynos5420 compatible for the MIPI video phyFor some reason, the driver adding support for Exynos5420 MIPI phyback in 2016 wasn't used on Exynos5420, which caused a kernel panic.Add the proper compatible for it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53545 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: unmap and remove csa_va properlyRoot PD BO should be reserved before unmap and removea bo_va from VM otherwise lockdep will complain.v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu][14616.937096] Call Trace:[14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu][14616.937187] drm_file_free+0x1d6/0x300 [drm][14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm][14616.937220] drm_release+0x5e/0x100 [drm][14616.937234] __fput+0x9f/0x280[14616.937239] ____fput+0xe/0x20[14616.937241] task_work_run+0x61/0x90[14616.937246] exit_to_user_mode_prepare+0x215/0x220[14616.937251] syscall_exit_to_user_mode+0x2a/0x60[14616.937254] do_syscall_64+0x48/0x90[14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53546 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, fix memory leak in mlx5dr_cmd_create_reformat_ctxwhen mlx5_cmd_exec failed in mlx5dr_cmd_create_reformat_ctx, the memorypointed by 'in' is not released, which will cause memory leak. Move memoryrelease after mlx5_cmd_exec.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usbnet: Fix WARNING in usbnet_start_xmit/usb_submit_urbThe syzbot fuzzer identified a problem in the usbnet driver:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 0 PID: 754 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 754 Comm: kworker/0:2 Not tainted 6.4.0-rc7-syzkaller-00014-g692b7dc87ca6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 2c b4 5b fb 48 8b 7c 24 18 e8 42 07 f0 fe 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 c9 fc 8a e8 5a 6f 23 fb <0f> 0b e9 58 f8 ff ff e8 fe b3 5b fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc9000463f568 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000RDX: ffff88801eb28000 RSI: ffffffff814c03b7 RDI: 0000000000000001RBP: ffff8881443b7190 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000003R13: ffff88802a77cb18 R14: 0000000000000003 R15: ffff888018262500FS: 0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556a99c15a18 CR3: 0000000028c71000 CR4: 0000000000350ef0Call Trace: usbnet_start_xmit+0xfe5/0x2190 drivers/net/usb/usbnet.c:1453 __netdev_start_xmit include/linux/netdevice.h:4918 [inline] netdev_start_xmit include/linux/netdevice.h:4932 [inline] xmit_one net/core/dev.c:3578 [inline] dev_hard_start_xmit+0x187/0x700 net/core/dev.c:3594...This bug is caused by the fact that usbnet trusts the bulk endpointaddresses its probe routine receives in the driver_info structure, andit does not check to see that these endpoints actually exist and havethe expected type and directions.The fix is simply to add such a check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Rework long task execution when adding/deleting entriesWhen adding/deleting large number of elements in one step in ipset, it cantake a reasonable amount of time and can result in soft lockup errors. Thepatch 5f7b51bf09ba ("netfilter: ipset: Limit the maximal range ofconsecutive elements to add/delete") tried to fix it by limiting the maxelements to process at all. However it was not enough, it is still possiblethat we get hung tasks. Lowering the limit is not reasonable, so theapproach in this patch is as follows: rely on the method used at resizingsets and save the state when we reach a smaller internal batch limit,unlock/lock and proceed from the saved state. Thus we can avoid longcontinuous tasks and at the same time removed the limit to add/delete largenumber of elements in one step.The nfnl mutex is held during the whole operation which prevents one toissue other ipset commands in parallel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53551 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Add null pointer check in gserial_resumeConsider a case where gserial_disconnect has already clearedgser->ioport. And if a wakeup interrupt triggers afterwards,gserial_resume gets called, which will lead to accessing ofgser->ioport and thus causing null pointer dereference.Adda null pointer check to prevent this.Added a static spinlock to prevent gser->ioport from becomingnull after the newly added check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53552 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: mark requests for GuC virtual engines to avoid use-after-freeReferences to i915_requests may be trapped by userspace inside async_file or dmabuf (dma-resv) and held indefinitely across differentproceses. To counter-act the memory leaks, we try to not to keepreferences from the request past their completion.On the other side on fence release we need to know if rq->engineis valid and points to hw engine (true for non-virtual requests).To make it possible extra bit has been added to rq->execution_mask,for marking virtual engines.(cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53553 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hyperv: avoid struct memcpy overrun warningA previous patch addressed the fortified memcpy warning for mostbuilds, but I still see this one with gcc-9:In file included from include/linux/string.h:254, from drivers/hid/hid-hyperv.c:8:In function 'fortify_memcpy_chk', inlined from 'mousevsc_on_receive' at drivers/hid/hid-hyperv.c:272:3:include/linux/fortify-string.h:583:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning] 583 | __write_overflow_field(p_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~My guess is that the WARN_ON() itself is what confuses gcc, so it nolonger sees that there is a correct range check. Rework the code in away that helps readability and avoids the warning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53554 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: ks7010: potential buffer overflow in ks_wlan_set_encode_ext()The "exc->key_len" is a u16 that comes from the user. If it's overIW_ENCODING_TOKEN_MAX (64) that could lead to memory corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53556 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: Fix use-after-free in free_netdevWe do netif_napi_add() for all allocated q_vectors[], but potentiallydo netif_napi_del() for part of them, then kfree q_vectors and leaveinvalid pointers at dev->napi_list.Reproducer: [root@host ~]# cat repro.sh #!/bin/bash pf_dbsf="0000:41:00.0" vf0_dbsf="0000:41:02.0" g_pids=() function do_set_numvf() { echo 2 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) echo 0 >/sys/bus/pci/devices/${pf_dbsf}/sriov_numvfs sleep $((RANDOM%3+1)) } function do_set_channel() { local nic=$(ls -1 --indicator-style=none /sys/bus/pci/devices/${vf0_dbsf}/net/) [ -z "$nic" ] && { sleep $((RANDOM%3)) ; return 1; } ifconfig $nic 192.168.18.5 netmask 255.255.255.0 ifconfig $nic up ethtool -L $nic combined 1 ethtool -L $nic combined 4 sleep $((RANDOM%3)) } function on_exit() { local pid for pid in "${g_pids[@]}"; do kill -0 "$pid" &>/dev/null && kill "$pid" &>/dev/null done g_pids=() } trap "on_exit; exit" EXIT while :; do do_set_numvf ; done & g_pids+=($!) while :; do do_set_channel ; done & g_pids+=($!) waitResult:[ 4093.900222] ==================================================================[ 4093.900230] BUG: KASAN: use-after-free in free_netdev+0x308/0x390[ 4093.900232] Read of size 8 at addr ffff88b4dc145640 by task repro.sh/6699[ 4093.900233][ 4093.900236] CPU: 10 PID: 6699 Comm: repro.sh Kdump: loaded Tainted: G O --------- -t - 4.18.0 #1[ 4093.900238] Hardware name: Powerleader PR2008AL/H12DSi-N6, BIOS 2.0 04/09/2021[ 4093.900239] Call Trace:[ 4093.900244] dump_stack+0x71/0xab[ 4093.900249] print_address_description+0x6b/0x290[ 4093.900251] ? free_netdev+0x308/0x390[ 4093.900252] kasan_report+0x14a/0x2b0[ 4093.900254] free_netdev+0x308/0x390[ 4093.900261] iavf_remove+0x825/0xd20 [iavf][ 4093.900265] pci_device_remove+0xa8/0x1f0[ 4093.900268] device_release_driver_internal+0x1c6/0x460[ 4093.900271] pci_stop_bus_device+0x101/0x150[ 4093.900273] pci_stop_and_remove_bus_device+0xe/0x20[ 4093.900275] pci_iov_remove_virtfn+0x187/0x420[ 4093.900277] ? pci_iov_add_virtfn+0xe10/0xe10[ 4093.900278] ? pci_get_subsys+0x90/0x90[ 4093.900280] sriov_disable+0xed/0x3e0[ 4093.900282] ? bus_find_device+0x12d/0x1a0[ 4093.900290] i40e_free_vfs+0x754/0x1210 [i40e][ 4093.900298] ? i40e_reset_all_vfs+0x880/0x880 [i40e][ 4093.900299] ? pci_get_device+0x7c/0x90[ 4093.900300] ? pci_get_subsys+0x90/0x90[ 4093.900306] ? pci_vfs_assigned.part.7+0x144/0x210[ 4093.900309] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900315] i40e_pci_sriov_configure+0x1fa/0x2e0 [i40e][ 4093.900318] sriov_numvfs_store+0x214/0x290[ 4093.900320] ? sriov_totalvfs_show+0x30/0x30[ 4093.900321] ? __mutex_lock_slowpath+0x10/0x10[ 4093.900323] ? __check_object_size+0x15a/0x350[ 4093.900326] kernfs_fop_write+0x280/0x3f0[ 4093.900329] vfs_write+0x145/0x440[ 4093.900330] ksys_write+0xab/0x160[ 4093.900332] ? __ia32_sys_read+0xb0/0xb0[ 4093.900334] ? fput_many+0x1a/0x120[ 4093.900335] ? filp_close+0xf0/0x130[ 4093.900338] do_syscall_64+0xa0/0x370[ 4093.900339] ? page_fault+0x8/0x30[ 4093.900341] entry_SYSCALL_64_after_hwframe+0x65/0xca[ 4093.900357] RIP: 0033:0x7f16ad4d22c0[ 4093.900359] Code: 73 01 c3 48 8b 0d d8 cb 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 89 24 2d 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 fe dd 01 00 48 89 04 24[ 4093.900360] RSP: 002b:00007ffd6491b7f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ 4093.900362] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f16ad4d22c0[ 4093.900363] RDX: 0000000000000002 RSI: 0000000001a41408 RDI: 0000000000000001[ 4093.900364] RBP: 0000000001a41408 R08: 00007f16ad7a1780 R09: 00007f16ae1f2700[ 4093.9003---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip_vti: fix potential slab-use-after-free in decode_session6When ip_vti device is set to the qdisc of the sfb type, the cb fieldof the sent skb may be modified during enqueuing. Then,slab-use-after-free may occur when ip_vti device sends IPv6 packets.As commit f855691975bb ("xfrm6: Fix the nexthdr offset in_decode_session6.") showed, xfrm_decode_session was originally intendedonly for the receive path. IP6CB(skb)->nhoff is not set duringtransmission. Therefore, set the cb field in the skb to 0 beforesending packets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53560 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing/histograms: Add histograms to hist_vars if they have referenced variablesHist triggers can have referenced variables without having directvariables fields. This can be the case if referenced variables are addedfor trigger actions. In this case the newly added references will nothave field variables. Not taking such referenced variables intoconsideration can result in a bug where it would be possible to removehist trigger with variables being refenced. This will result in a bugthat is easily reproducable like so$ cd /sys/kernel/tracing$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger[ 100.263533] ==================================================================[ 100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180[ 100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439[ 100.266320][ 100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4[ 100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014[ 100.268561] Call Trace:[ 100.268902] [ 100.269189] dump_stack_lvl+0x4c/0x70[ 100.269680] print_report+0xc5/0x600[ 100.270165] ? resolve_var_refs+0xc7/0x180[ 100.270697] ? kasan_complete_mode_report_info+0x80/0x1f0[ 100.271389] ? resolve_var_refs+0xc7/0x180[ 100.271913] kasan_report+0xbd/0x100[ 100.272380] ? resolve_var_refs+0xc7/0x180[ 100.272920] __asan_load8+0x71/0xa0[ 100.273377] resolve_var_refs+0xc7/0x180[ 100.273888] event_hist_trigger+0x749/0x860[ 100.274505] ? kasan_save_stack+0x2a/0x50[ 100.275024] ? kasan_set_track+0x29/0x40[ 100.275536] ? __pfx_event_hist_trigger+0x10/0x10[ 100.276138] ? ksys_write+0xd1/0x170[ 100.276607] ? do_syscall_64+0x3c/0x90[ 100.277099] ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 100.277771] ? destroy_hist_data+0x446/0x470[ 100.278324] ? event_hist_trigger_parse+0xa6c/0x3860[ 100.278962] ? __pfx_event_hist_trigger_parse+0x10/0x10[ 100.279627] ? __kasan_check_write+0x18/0x20[ 100.280177] ? mutex_unlock+0x85/0xd0[ 100.280660] ? __pfx_mutex_unlock+0x10/0x10[ 100.281200] ? kfree+0x7b/0x120[ 100.281619] ? ____kasan_slab_free+0x15d/0x1d0[ 100.282197] ? event_trigger_write+0xac/0x100[ 100.282764] ? __kasan_slab_free+0x16/0x20[ 100.283293] ? __kmem_cache_free+0x153/0x2f0[ 100.283844] ? sched_mm_cid_remote_clear+0xb1/0x250[ 100.284550] ? __pfx_sched_mm_cid_remote_clear+0x10/0x10[ 100.285221] ? event_trigger_write+0xbc/0x100[ 100.285781] ? __kasan_check_read+0x15/0x20[ 100.286321] ? __bitmap_weight+0x66/0xa0[ 100.286833] ? _find_next_bit+0x46/0xe0[ 100.287334] ? task_mm_cid_work+0x37f/0x450[ 100.287872] event_triggers_call+0x84/0x150[ 100.288408] trace_event_buffer_commit+0x339/0x430[ 100.289073] ? ring_buffer_event_data+0x3f/0x60[ 100.292189] trace_event_raw_event_sys_enter+0x8b/0xe0[ 100.295434] syscall_trace_enter.constprop.0+0x18f/0x1b0[ 100.298653] syscall_enter_from_user_mode+0x32/0x40[ 100.301808] do_syscall_64+0x1a/0x90[ 100.304748] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 100.307775] RIP: 0033:0x7f686c75c1cb[ 100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48[ 100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021[ 100.321200] RA---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53561 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: wwan: iosm: fix NULL pointer dereference when removing deviceIn suspend and resume cycle, the removal and rescan of device endsup in NULL pointer dereference.During driver initialization, if the ipc_imem_wwan_channel_init()fails to get the valid device capabilities it returns an error andfurther no resource (wwan struct) will be allocated. Now in thissituation if driver removal procedure is initiated it would resultin NULL pointer exception since unallocated wwan struct is dereferencedinside ipc_wwan_deinit().ipc_imem_run_state_worker() to handle the called functions return valueand to release the resource in failure case. It also reports the linkdown event in failure cases. The user space application can handle thisevent to do a device reset for restoring the device communication.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: fix vram leak on bind errorsMake sure to release the VRAM buffer also in a case a subcomponent failsto bind.Patchwork: https://patchwork.freedesktop.org/patch/525094/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53564 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix defrag path triggering jbd2 ASSERTcode path:ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERTcrash stacks:PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2]AnalysisThis bug has the same root cause of 'commit 7f27ec978b0e ("ocfs2: callocfs2_journal_access_di() before ocfs2_journal_dirty() inocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() iscalled by ocfs2_split_extent() during defragmenting.How to fixFor ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller onlyneeds to call journal start/stop pair. The fix method is to removejournal access/dirty from __ocfs2_move_extent().The discussion for this patch:https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53566 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: fix null deref on element insertionThere is no guarantee that rb_prev() will not return NULL in nft_rbtree_gc_elem():general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] nft_add_set_elem+0x14b0/0x2990 nf_tables_newsetelem+0x528/0xb30Furthermore, there is a possible use-after-free while iterating,'node' can be free'd so we need to cache the next value to use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53567 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: qup: Don't skip cleanup in remove's error pathReturning early in a platform driver's remove callback is wrong. In thiscase the dma resources are not released in the error path. this is neverretried later and so this is a permanent leak. To fix this, only skiphardware disabling if waking the device fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53568 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: don't leak memory if dev_set_name() failsWhen dev_set_name() fails, zcdn_create() doesn't free the newlyallocated resources. Do it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53571 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Make intel_get_crtc_new_encoder() less oopsyThe point of the WARN was to print something, not oopsstraight up. Currently that is precisely what happensif we can't find the connector for the crtc in the atomicstate. Get the dev pointer from the atomic state insteadof the potentially NULL encoder to avoid that.(cherry picked from commit 3b6692357f70498f617ea1b31a0378070a0acf1c)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53572 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: scu: use _safe list iterator to avoid a use after freeThis loop is freeing "clk" so it needs to use list_for_each_entry_safe().Otherwise it dereferences a freed variable to get the next item on theloop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: Always check queue mode setting from configfsMake sure to check device queue mode in the null_validate_conf() andreturn error for NULL_Q_RQ as we don't allow legacy I/O path, withoutthis patch we get OOPs when queue mode is set to 1 from configfs,following are repro steps :-modprobe null_blk nr_devices=0mkdir config/nullb/nullb0echo 1 > config/nullb/nullb0/memory_backedecho 4096 > config/nullb/nullb0/blocksizeecho 20480 > config/nullb/nullb0/sizeecho 1 > config/nullb/nullb0/queue_modeecho 1 > config/nullb/nullb0/powerEntering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)due to oops @ 0xffffffffc041c329CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 <48> 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48aDR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400Call Trace: nullb_device_power_store+0xd1/0x120 [null_blk] configfs_write_iter+0xb4/0x120 vfs_write+0x2ba/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7fd4460c57a7Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53577 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, cpumap: Make sure kthread is running before map update returnsThe following warning was reported when running stress-mode enabledxdp_redirect_cpu with some RT threads: ------------[ cut here ]------------ WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135 CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Workqueue: events cpu_map_kthread_stop RIP: 0010:put_cpu_map_entry+0xda/0x220 ...... Call Trace: ? show_regs+0x65/0x70 ? __warn+0xa5/0x240 ...... ? put_cpu_map_entry+0xda/0x220 cpu_map_kthread_stop+0x41/0x60 process_one_work+0x6b0/0xb80 worker_thread+0x96/0x720 kthread+0x1a5/0x1f0 ret_from_fork+0x3a/0x70 ret_from_fork_asm+0x1b/0x30 The root cause is the same as commit 436901649731 ("bpf: cpumap: Fix memoryleak in cpu_map_update_elem"). The kthread is stopped prematurely bykthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't callcpu_map_kthread_run() at all but XDP program has already queued someframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checksthe ptr_ring, it will find it was not emptied and report a warning.An alternative fix is to use __cpu_map_ring_cleanup() to drop thesepending frames or skbs when kthread_stop() returns -EINTR, but it mayconfuse the user, because these frames or skbs have been handledcorrectly by XDP program. So instead of dropping these frames or skbs,just make sure the per-cpu kthread is running before__cpu_map_entry_alloc() returns.After apply the fix, the error handle for kthread_stop() will beunnecessary because it will always return 0, so just remove it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qrtr: Fix an uninit variable access bug in qrtr_tx_resume()Syzbot reported a bug as following:=====================================================BUG: KMSAN: uninit-value in qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_tx_resume+0x185/0x1f0 net/qrtr/af_qrtr.c:230 qrtr_endpoint_post+0xf85/0x11b0 net/qrtr/af_qrtr.c:519 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at: slab_post_alloc_hook mm/slab.h:766 [inline] slab_alloc_node mm/slub.c:3452 [inline] __kmem_cache_alloc_node+0x71f/0xce0 mm/slub.c:3491 __do_kmalloc_node mm/slab_common.c:967 [inline] __kmalloc_node_track_caller+0x114/0x3b0 mm/slab_common.c:988 kmalloc_reserve net/core/skbuff.c:492 [inline] __alloc_skb+0x3af/0x8f0 net/core/skbuff.c:565 __netdev_alloc_skb+0x120/0x7d0 net/core/skbuff.c:630 qrtr_endpoint_post+0xbd/0x11b0 net/qrtr/af_qrtr.c:446 qrtr_tun_write_iter+0x270/0x400 net/qrtr/tun.c:108 call_write_iter include/linux/fs.h:2189 [inline] aio_write+0x63a/0x950 fs/aio.c:1600 io_submit_one+0x1d1c/0x3bf0 fs/aio.c:2019 __do_sys_io_submit fs/aio.c:2078 [inline] __se_sys_io_submit+0x293/0x770 fs/aio.c:2048 __x64_sys_io_submit+0x92/0xd0 fs/aio.c:2048 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdIt is because that skb->len requires at least sizeof(struct qrtr_ctrl_pkt)in qrtr_tx_resume(). And skb->len equals to size in qrtr_endpoint_post().But size is less than sizeof(struct qrtr_ctrl_pkt) when qrtr_cb->typeequals to QRTR_TYPE_RESUME_TX in qrtr_endpoint_post() under the syzbotscenario. This triggers the uninit variable access bug.Add size check when qrtr_cb->type equals to QRTR_TYPE_RESUME_TX inqrtr_endpoint_post() to fix the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53579 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: mvebu: fix irq domain leakUwe Kleine-K?nig pointed out we still have one resource leak in the mvebudriver triggered on driver detach. Let's address it with a custom devmaction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53580 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: Gadget: core: Help prevent panic during UVC unconfigureAvichal Rakesh reported a kernel panic that occurred when the UVCgadget driver was removed from a gadget's configuration. The panicinvolves a somewhat complicated interaction between the kernel driverand a userspace component (as described in the Link tag below), butthe analysis did make one thing clear: The Gadget core shouldaccomodate gadget drivers calling usb_gadget_deactivate() as part oftheir unbind procedure.Currently this doesn't work. gadget_unbind_driver() callsdriver->unbind() while holding the udc->connect_lock mutex, andusb_gadget_deactivate() attempts to acquire that mutex, which willresult in a deadlock.The simple fix is for gadget_unbind_driver() to release the mutex wheninvoking the ->unbind() callback. There is no particular reason forit to be holding the mutex at that time, and the mutex isn't heldwhile the ->bind() callback is invoked. So we'll drop the mutexbefore performing the unbind callback and reacquire it afterward.We'll also add a couple of comments to usb_gadget_activate() andusb_gadget_deactivate(). Because they run in process context theymust not be called from a gadget driver's ->disconnect() callback,which (according to the kerneldoc for struct usb_gadget_driver ininclude/linux/usb/gadget.h) may run in interrupt context. This mayhelp prevent similar bugs from arising in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53591 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix deadlock in tc route query codeCited commit causes ABBA deadlock[0] when peer flows are created whileholding the devcom rw semaphore. Due to peer flows offload implementationthe lock is taken much higher up the call chain and there is no obvious wayto easily fix the deadlock. Instead, since tc route query code needs thepeer eswitch structure only to perform a lookup in xarray and doesn'tperform any sleeping operations with it, refactor the code for locklessexecution in following ways:- RCUify the devcom 'data' pointer. When resetting the pointersynchronously wait for RCU grace period before returning. This is finesince devcom is currently only used for synchronization ofpairing/unpairing of eswitches which is rare and already expensive as-is.- Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag hasalready been used in some unlocked contexts without properannotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn'tan issue since all relevant code paths checked it again after obtaining thedevcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as"best effort" check to return NULL when devcom is being unpaired. Note thatwhile RCU read lock doesn't prevent the unpaired flag from being changedconcurrently it still guarantees that reader can continue to use 'data'.- Refactor mlx5e_tc_query_route_vport() function to use newmlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.[0]:[ 164.599612] ======================================================[ 164.600142] WARNING: possible circular locking dependency detected[ 164.600667] 6.3.0-rc3+ #1 Not tainted[ 164.601021] ------------------------------------------------------[ 164.601557] handler1/3456 is trying to acquire lock:[ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.603078] but task is already holding lock:[ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.604459] which lock already depends on the new lock.[ 164.605190] the existing dependency chain (in reverse order) is:[ 164.605848] -> #1 (&comp->sem){++++}-{3:3}:[ 164.606380] down_read+0x39/0x50[ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core][ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core][ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core][ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core][ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core][ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core][ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core][ 164.610741] tc_setup_cb_add+0xd4/0x200[ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower][ 164.611661] fl_change+0xc95/0x18a0 [cls_flower][ 164.612116] tc_new_tfilter+0x3fc/0xd20[ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0[ 164.612936] netlink_rcv_skb+0x54/0x100[ 164.613339] netlink_unicast+0x190/0x250[ 164.613746] netlink_sendmsg+0x245/0x4a0[ 164.614150] sock_sendmsg+0x38/0x60[ 164.614522] ____sys_sendmsg+0x1d0/0x1e0[ 164.614934] ___sys_sendmsg+0x80/0xc0[ 164.615320] __sys_sendmsg+0x51/0x90[ 164.615701] do_syscall_64+0x3d/0x90[ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0[ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}:[ 164.617210] __lock_acquire+0x159e/0x26e0[ 164.617638] lock_acquire+0xc2/0x2a0[ 164.618018] __mutex_lock+0x92/0xcd0[ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core][ 164.618943] post_process_attr+0x153/0x2d0 [---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver core: fix resource leak in device_add()When calling kobject_add() failed in device_add(), it will callcleanup_glue_dir() to free resource. But in kobject_add(),dev->kobj.parent has been set to NULL. This will cause resource leak.The process is as follows:device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put()The preceding problem may cause insmod mac80211_hwsim.ko to failed.sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'Call Trace:dump_stack_lvl+0x8e/0xd1sysfs_warn_dup.cold+0x1c/0x29sysfs_create_dir_ns+0x224/0x280kobject_add_internal+0x2aa/0x880kobject_add+0x135/0x1a0get_device_parent+0x3d7/0x590device_add+0x2aa/0x1cb0device_create_groups_vargs+0x1eb/0x260device_create+0xdc/0x110mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]do_one_initcall+0x10f/0x630do_init_module+0x19f/0x5e0load_module+0x64b7/0x6eb0__do_sys_finit_module+0x140/0x200do_syscall_64+0x35/0x80entry_SYSCALL_64_after_hwframe+0x46/0xb0kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try toregister things with the same name in the same directory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: base: Free devm resources when unregistering a deviceIn the current code, devres_release_all() only gets called if the devicehas a bus and has been probed.This leads to issues when using bus-less or driver-less devices wherethe device might never get freed if a managed resource holds a referenceto the device. This is happening in the DRM framework for example.We should thus call devres_release_all() in the device_del() function tomake sure that the device-managed actions are properly executed when thedevice is unregistered, even if it has neither a bus nor a driver.This is effectively the same change than commit 2f8d16a996da ("devres:release resources on device_del()") that got reverted by commita525a3ddeaca ("driver core: free devres in device_release") overmemory leaks concerns.This patch effectively combines the two commits mentioned above torelease the resources both on device_del() and device_release() and getthe best of both worlds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53597 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix mid leak during reconnection after timeout thresholdWhen the number of responses with status of STATUS_IO_TIMEOUTexceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnectthe connection. But we do not return the mid, or the creditsreturned for the mid, or reduce the number of in-flight requests.This bug could result in the server->in_flight count to go bad,and also cause a leak in the mids.This change moves the check to a few lines below where theresponse is decrypted, even of the response is read from thetransform header. This way, the code for returning the midscan be reused.Also, the cifs_reconnect was reconnecting just the transportconnection before. In case of multi-channel, this may not bewhat we want to do after several timeouts. Changed that toreconnect the session and the tree too.Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate nameMAX_STATUS_IO_TIMEOUT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53598 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Range check CHDBOFF and ERDBOFFIf the value read from the CHDBOFF and ERDBOFF registers is outside therange of the MHI register space then an invalid address might be computedwhich later causes a kernel panic. Range check the read value to preventa crash due to bad data from the device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53600 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tunnels: fix kasan splat when generating ipv4 pmtu errorIf we try to emit an icmp error in response to a nonliner skb, we getBUG: KASAN: slab-out-of-bounds in ip_compute_csum+0x134/0x220Read of size 4 at addr ffff88811c50db00 by task iperf3/1691CPU: 2 PID: 1691 Comm: iperf3 Not tainted 6.5.0-rc3+ #309[..] kasan_report+0x105/0x140 ip_compute_csum+0x134/0x220 iptunnel_pmtud_build_icmp+0x554/0x1020 skb_tunnel_check_pmtu+0x513/0xb80 vxlan_xmit_one+0x139e/0x2ef0 vxlan_xmit+0x1867/0x2760 dev_hard_start_xmit+0x1ee/0x4f0 br_dev_queue_push_xmit+0x4d1/0x660 [..]ip_compute_csum() cannot deal with nonlinear skbs, so avoid it.After this change, splat is gone and iperf3 is no longer stuck.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53601 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: do not assume skb mac_header is setDrivers must not assume in their ndo_start_xmit() thatskbs have their mac_header set. skb->data is all what is needed.bonding seems to be one of the last offender as caught by syzbot:WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 skb_mac_offset include/linux/skbuff.h:2913 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 __bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]WARNING: CPU: 1 PID: 12155 at include/linux/skbuff.h:2907 bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Modules linked in:CPU: 1 PID: 12155 Comm: syz-executor.3 Not tainted 6.1.30-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023RIP: 0010:skb_mac_header include/linux/skbuff.h:2907 [inline]RIP: 0010:skb_mac_offset include/linux/skbuff.h:2913 [inline]RIP: 0010:bond_xmit_hash drivers/net/bonding/bond_main.c:4170 [inline]RIP: 0010:bond_xmit_3ad_xor_slave_get drivers/net/bonding/bond_main.c:5149 [inline]RIP: 0010:bond_3ad_xor_xmit drivers/net/bonding/bond_main.c:5186 [inline]RIP: 0010:__bond_start_xmit drivers/net/bonding/bond_main.c:5442 [inline]RIP: 0010:bond_start_xmit+0x14ab/0x19d0 drivers/net/bonding/bond_main.c:5470Code: 8b 7c 24 30 e8 76 dd 1a 01 48 85 c0 74 0d 48 89 c3 e8 29 67 2e fe e9 15 ef ff ff e8 1f 67 2e fe e9 10 ef ff ff e8 15 67 2e fe <0f> 0b e9 45 f8 ff ff e8 09 67 2e fe e9 dc fa ff ff e8 ff 66 2e feRSP: 0018:ffffc90002fff6e0 EFLAGS: 00010283RAX: ffffffff835874db RBX: 000000000000ffff RCX: 0000000000040000RDX: ffffc90004dcf000 RSI: 00000000000000b5 RDI: 00000000000000b6RBP: ffffc90002fff8b8 R08: ffffffff83586d16 R09: ffffffff83586584R10: 0000000000000007 R11: ffff8881599fc780 R12: ffff88811b6a7b7eR13: 1ffff110236d4f6f R14: ffff88811b6a7ac0 R15: 1ffff110236d4f76FS: 00007f2e9eb47700(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b2e421000 CR3: 000000010e6d4000 CR4: 00000000003526e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] __dev_direct_xmit+0x4ef/0x850 net/core/dev.c:4380[] dev_direct_xmit include/linux/netdevice.h:3043 [inline][] packet_direct_xmit+0x18b/0x300 net/packet/af_packet.c:284[] packet_snd net/packet/af_packet.c:3112 [inline][] packet_sendmsg+0x4a22/0x64d0 net/packet/af_packet.c:3143[] sock_sendmsg_nosec net/socket.c:716 [inline][] sock_sendmsg net/socket.c:736 [inline][] __sys_sendto+0x472/0x5f0 net/socket.c:2139[] __do_sys_sendto net/socket.c:2151 [inline][] __se_sys_sendto net/socket.c:2147 [inline][] __x64_sys_sendto+0xe5/0x100 net/socket.c:2147[] do_syscall_x64 arch/x86/entry/common.c:50 [inline][] do_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80[] entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53603 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Avoid fcport pointer dereferenceKlocwork reported warning of NULL pointer may be dereferenced. The routineexits when sa_ctl is NULL and fcport is allocated after the exit call thuscausing NULL fcport pointer to dereference at the time of exit.To avoid fcport pointer dereference, exit the routine when sa_ctl is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53607 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ymfpci: Fix BUG_ON in probe functionThe snd_dma_buffer.bytes field now contains the aligned size, which thissnd_BUG_ON() did not account for, resulting in the following:[ 9.625915] ------------[ cut here ]------------[ 9.633440] WARNING: CPU: 0 PID: 126 at sound/pci/ymfpci/ymfpci_main.c:2168 snd_ymfpci_create+0x681/0x698 [snd_ymfpci][ 9.648926] Modules linked in: snd_ymfpci(+) snd_intel_dspcfg kvm(+) snd_intel_sdw_acpi snd_ac97_codec snd_mpu401_uart snd_opl3_lib irqbypass snd_hda_codec gameport snd_rawmidi crct10dif_pclmul crc32_pclmul cfg80211 snd_hda_core polyval_clmulni polyval_generic gf128mul snd_seq_device ghash_clmulni_intel snd_hwdep ac97_bus sha512_ssse3 rfkill snd_pcm aesni_intel tg3 snd_timer crypto_simd snd mxm_wmi libphy cryptd k10temp fam15h_power pcspkr soundcore sp5100_tco wmi acpi_cpufreq mac_hid dm_multipath sg loop fuse dm_mod bpf_preload ip_tables x_tables ext4 crc32c_generic crc16 mbcache jbd2 sr_mod cdrom ata_generic pata_acpi firewire_ohci crc32c_intel firewire_core xhci_pci crc_itu_t pata_via xhci_pci_renesas floppy[ 9.711849] CPU: 0 PID: 126 Comm: kworker/0:2 Not tainted 6.1.21-1-lts #1 08d2e5ece03136efa7c6aeea9a9c40916b1bd8da[ 9.722200] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./990FX Extreme4, BIOS P2.70 06/05/2014[ 9.732204] Workqueue: events work_for_cpu_fn[ 9.736580] RIP: 0010:snd_ymfpci_create+0x681/0x698 [snd_ymfpci][ 9.742594] Code: 8c c0 4c 89 e2 48 89 df 48 c7 c6 92 c6 8c c0 e8 15 d0 e9 ff 48 83 c4 08 44 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f e9 d3 7a 33 e3 <0f> 0b e9 cb fd ff ff 41 bd fb ff ff ff eb db 41 bd f4 ff ff ff eb[ 9.761358] RSP: 0018:ffffab64804e7da0 EFLAGS: 00010287[ 9.766594] RAX: ffff8fa2df06c400 RBX: ffff8fa3073a8000 RCX: ffff8fa303fbc4a8[ 9.773734] RDX: ffff8fa2df06d000 RSI: 0000000000000010 RDI: 0000000000000020[ 9.780876] RBP: ffff8fa300b5d0d0 R08: ffff8fa3073a8e50 R09: 00000000df06bf00[ 9.788018] R10: ffff8fa2df06bf00 R11: 00000000df068200 R12: ffff8fa3073a8918[ 9.795159] R13: 0000000000000000 R14: 0000000000000080 R15: ffff8fa2df068200[ 9.802317] FS: 0000000000000000(0000) GS:ffff8fa9fec00000(0000) knlGS:0000000000000000[ 9.810414] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 9.816158] CR2: 000055febaf66500 CR3: 0000000101a2e000 CR4: 00000000000406f0[ 9.823301] Call Trace:[ 9.825747] [ 9.827889] snd_card_ymfpci_probe+0x194/0x950 [snd_ymfpci b78a5fe64b5663a6390a909c67808567e3e73615][ 9.837030] ? finish_task_switch.isra.0+0x90/0x2d0[ 9.841918] local_pci_probe+0x45/0x80[ 9.845680] work_for_cpu_fn+0x1a/0x30[ 9.849431] process_one_work+0x1c7/0x380[ 9.853464] worker_thread+0x1af/0x390[ 9.857225] ? rescuer_thread+0x3b0/0x3b0[ 9.861254] kthread+0xde/0x110[ 9.864414] ? kthread_complete_and_exit+0x20/0x20[ 9.869210] ret_from_fork+0x22/0x30[ 9.872792] [ 9.874985] ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53610 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip: Fix refcount leak in platform_irqchip_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53611 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi_si: fix a memleak in try_smi_init()Kmemleak reported the following leak info in try_smi_init():unreferenced object 0xffff00018ecf9400 (size 1024): comm "modprobe", pid 2707763, jiffies 4300851415 (age 773.308s) backtrace: [<000000004ca5b312>] __kmalloc+0x4b8/0x7b0 [<00000000953b1072>] try_smi_init+0x148/0x5dc [ipmi_si] [<000000006460d325>] 0xffff800081b10148 [<0000000039206ea5>] do_one_initcall+0x64/0x2a4 [<00000000601399ce>] do_init_module+0x50/0x300 [<000000003c12ba3c>] load_module+0x7a8/0x9e0 [<00000000c246fffe>] __se_sys_init_module+0x104/0x180 [<00000000eea99093>] __arm64_sys_init_module+0x24/0x30 [<0000000021b1ef87>] el0_svc_common.constprop.0+0x94/0x250 [<0000000070f4f8b7>] do_el0_svc+0x48/0xe0 [<000000005a05337f>] el0_svc+0x24/0x3c [<000000005eb248d6>] el0_sync_handler+0x160/0x164 [<0000000030a59039>] el0_sync+0x160/0x180The problem was that when an error occurred before handlers registrationand after allocating `new_smi->si_sm`, the variable wouldn't be freed inthe error handling afterwards since `shutdown_smi()` hadn't beenregistered yet. Fix it by adding a `kfree()` in the error handling pathin `try_smi_init()`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53613 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dax: Fix dax_mapping_release() use after freeA CONFIG_DEBUG_KOBJECT_RELEASE test of removing a device-dax regionprovider (like modprobe -r dax_hmem) yields: kobject: 'mapping0' (ffff93eb460e8800): kobject_release, parent 0000000000000000 (delayed 2000) [..] DEBUG_LOCKS_WARN_ON(1) WARNING: CPU: 23 PID: 282 at kernel/locking/lockdep.c:232 __lock_acquire+0x9fc/0x2260 [..] RIP: 0010:__lock_acquire+0x9fc/0x2260 [..] Call Trace: [..] lock_acquire+0xd4/0x2c0 ? ida_free+0x62/0x130 _raw_spin_lock_irqsave+0x47/0x70 ? ida_free+0x62/0x130 ida_free+0x62/0x130 dax_mapping_release+0x1f/0x30 device_release+0x36/0x90 kobject_delayed_cleanup+0x46/0x150Due to attempting ida_free() on an ida object that has already beenfreed. Devices typically only hold a reference on their parent whileregistered. If a child needs a parent object to complete its release itneeds to hold a reference that it drops from its release callback.Arrange for a dax_mapping to pin its parent dev_dax instance untildax_mapping_release().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix deletion race conditionSystem crash when using debug kernel due to link list corruption. The causeof the link list corruption is due to session deletion was allowed to queueup twice. Here's the internal trace that show the same port was allowed todouble queue for deletion on different cpu.20808683956 015 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 120808683957 027 qla2xxx [0000:13:00.1]-e801:4: Scheduling sess ffff93ebf9306800 for deletion 50:06:0e:80:12:48:ff:50 fc4_type 1Move the clearing/setting of deleted flag lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53617 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: socinfo: Add kfree for kstrdupAdd kfree() in the later error handling in order to avoid memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53618 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reject invalid reloc tree root keys with stack dump[BUG]Syzbot reported a crash that an ASSERT() got triggered insideprepare_to_merge().That ASSERT() makes sure the reloc tree is properly pointed back by itssubvolume tree.[CAUSE]After more debugging output, it turns out we had an invalid reloc tree: BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17Note the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,QUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.But reloc trees can only exist for subvolumes, as for non-subvolumetrees, we just COW the involved tree block, no need to create a reloctree since those tree blocks won't be shared with other trees.Only subvolumes tree can share tree blocks with other trees (thus theyhave BTRFS_ROOT_SHAREABLE flag).Thus this new debug output proves my previous assumption that corruptedon-disk data can trigger that ASSERT().[FIX]Besides the dedicated fix and the graceful exit, also let tree-checker tocheck such root keys, to make sure reloc trees can only exist for subvolumes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53620 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix soft lockup in status_resyncstatus_resync() will calculate 'curr_resync - recovery_active' to showuser a progress bar like following:[============>........] resync = 61.4%'curr_resync' and 'recovery_active' is updated in md_do_sync(), andstatus_resync() can read them concurrently, hence it's possible that'curr_resync - recovery_active' can overflow to a huge number. In thiscase status_resync() will be stuck in the loop to print a large amountof '=', which will end up soft lockup.Fix the problem by setting 'resync' to MD_RESYNC_ACTIVE in this case,this way resync in progress will be reported to user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53625 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gvt: fix vgpu debugfs clean in removeCheck carefully on root debugfs available when destroying vgpu,e.g in remove case drm minor's debugfs root might already be destroyed,which led to kernel oops like below.Console: switching to colour dummy device 80x25i915 0000:00:02.0: MDEV: Unregisteringintel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14BUG: kernel NULL pointer dereference, address: 0000000000000150PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMPCPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6Hardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022RIP: 0010:__lock_acquire+0x5e2/0x1f90Code: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0RSP: 0018:ffff9f770274f948 EFLAGS: 00010046RAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000R13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000FS: 00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: lock_acquire+0xbf/0x2b0 ? simple_recursive_removal+0xa5/0x2b0 ? lock_release+0x13d/0x2d0 down_write+0x2a/0xd0 ? simple_recursive_removal+0xa5/0x2b0 simple_recursive_removal+0xa5/0x2b0 ? start_creating.part.0+0x110/0x110 ? _raw_spin_unlock+0x29/0x40 debugfs_remove+0x40/0x60 intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt] intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt] intel_vgpu_release_dev+0xe/0x20 [kvmgt] device_release+0x30/0x80 kobject_put+0x79/0x1b0 device_release_driver_internal+0x1b8/0x230 bus_remove_device+0xec/0x160 device_del+0x189/0x400 ? up_write+0x9c/0x1b0 ? mdev_device_remove_common+0x60/0x60 [mdev] mdev_device_remove_common+0x22/0x60 [mdev] mdev_device_remove_cb+0x17/0x20 [mdev] device_for_each_child+0x56/0x80 mdev_unregister_parent+0x5a/0x81 [mdev] intel_gvt_clean_device+0x2d/0xe0 [kvmgt] intel_gvt_driver_remove+0x2e/0xb0 [i915] i915_driver_remove+0xac/0x100 [i915] i915_pci_remove+0x1a/0x30 [i915] pci_device_remove+0x31/0xa0 device_release_driver_internal+0x1b8/0x230 unbind_store+0xd8/0x100 kernfs_fop_write_iter+0x156/0x210 vfs_write+0x236/0x4a0 ksys_write+0x61/0xd0 do_syscall_64+0x55/0x80 ? find_held_lock+0x2b/0x80 ? lock_release+0x13d/0x2d0 ? up_read+0x17/0x20 ? lock_is_held_type+0xe3/0x140 ? asm_exc_page_fault+0x22/0x30 ? lockdep_hardirqs_on+0x7d/0x100 entry_SYSCALL_64_after_hwframe+0x46/0xb0RIP: 0033:0x7fc9b2c9e0c4Code: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48RSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4RDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001RBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000dR13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00 Modules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Grab sas_dev lock when traversing the members of sas_dev.listWhen freeing slots in function slot_complete_v3_hw(), it is possible thatsas_dev.list is being traversed elsewhere, and it may trigger a NULLpointer exception, such as follows:==>cq thread ==>scsi_eh_6 ==>scsi_error_handler() ==>sas_eh_handle_sas_errors() ==>sas_scsi_find_task() ==>lldd_abort_task()==>slot_complete_v3_hw() ==>hisi_sas_abort_task() ==>hisi_sas_slot_task_free() ==>dereg_device_v3_hw() ==>list_del_init() ==>list_for_each_entry_safe()[ 7165.434918] sas: Enter sas_scsi_recover_host busy: 32 failed: 32[ 7165.434926] sas: trying to find task 0x00000000769b5ba5[ 7165.434927] sas: sas_scsi_find_task: aborting task 0x00000000769b5ba5[ 7165.434940] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted[ 7165.434964] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored[ 7165.434965] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored[ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 7165.434972] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored[ 7165.434975] hisi_sas_v3_hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored[ 7165.434976] Mem abort info:[ 7165.434982] ESR = 0x96000004[ 7165.434991] Exception class = DABT (current EL), IL = 32 bits[ 7165.434992] SET = 0, FnV = 0[ 7165.434993] EA = 0, S1PTW = 0[ 7165.434994] Data abort info:[ 7165.434994] ISV = 0, ISS = 0x00000004[ 7165.434995] CM = 0, WnR = 0[ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2[ 7165.434998] [0000000000000000] pgd=0000000000000000[ 7165.435003] Internal error: Oops: 96000004 [#1] SMP[ 7165.439863] Process scsi_eh_6 (pid: 4109, stack limit = 0x00000000c43818d5)[ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO)[ 7165.473637] pc : dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.479443] lr : dereg_device_v3_hw+0x2c/0xa8 [hisi_sas_v3_hw][ 7165.485247] sp : ffff00001d623bc0[ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508[ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8[ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8[ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00[ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8[ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff[ 7165.520276] x17: 0000000000000000 x16: 0000000000000000[ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8[ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067[ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0[ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00[ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00[ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e[ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000[ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e[ 7165.567872] Call trace:[ 7165.570309] dereg_device_v3_hw+0x68/0xa8 [hisi_sas_v3_hw][ 7165.575775] hisi_sas_abort_task+0x248/0x358 [hisi_sas_main][ 7165.581415] sas_eh_handle_sas_errors+0x258/0x8e0 [libsas][ 7165.586876] sas_scsi_recover_host+0x134/0x458 [libsas][ 7165.592082] scsi_error_handler+0xb4/0x488[ 7165.596163] kthread+0x134/0x138[ 7165.599380] ret_from_fork+0x10/0x18[ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021)[ 7165.609004] kernel fault(0x1) notification starting on CPU 75[ 7165.700728] ---[ end trace fc042cbbea224efc ]---[ 7165.705326] Kernel panic - not syncing: Fatal exceptionTo fix the issue, grab sas_dev lock when traversing the members ofsas_dev.list in dereg_device_v3_hw() and hisi_sas_release_tasks() to avoidconcurrency of adding and deleting member. When ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53631 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-sysman: Fix reference leakIf a duplicate attribute is found using kset_find_obj(),a reference to that attribute is returned. This meansthat we need to dispose it accordingly. Use kobject_put()to dispose the duplicate attribute in such a case.Compile-tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov772x: Fix memleak in ov772x_probe()A memory leak was reported when testing ov772x with bpf mock device:AssertionError: unreferenced object 0xffff888109afa7a8 (size 8): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 8 bytes): 80 22 88 15 81 88 ff ff ."...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev] [<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110 [<00000000a9f2159d>] of_i2c_notify+0x100/0x160unreferenced object 0xffff888119825c00 (size 256): comm "python3", pid 279, jiffies 4294805921 (age 20.681s) hex dump (first 32 bytes): 00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^...... 10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\...... backtrace: [<000000009990b438>] __kmalloc_node+0x44/0x1b0 [<000000009e32f7d7>] kvmalloc_node+0x34/0x180 [<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev] [<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x] [<000000003f0d225e>] i2c_device_probe+0x28d/0x680 [<00000000e0b6db89>] really_probe+0x17c/0x3f0 [<000000001b19fcee>] __driver_probe_device+0xe3/0x170 [<0000000048370519>] driver_probe_device+0x49/0x120 [<000000005ead07a0>] __device_attach_driver+0xf7/0x150 [<0000000043f452b8>] bus_for_each_drv+0x114/0x180 [<00000000358e5596>] __device_attach+0x1e5/0x2d0 [<0000000043f83c5d>] bus_probe_device+0x126/0x140 [<00000000ee0f3046>] device_add+0x810/0x1130 [<00000000e0278184>] i2c_new_client_device+0x359/0x4f0 [<0000000070baf34f>] of_i2c_register_device+0xf1/0x110The reason is that if priv->hdl.error is set, ov772x_probe() jumps to theerror_mutex_destroy without doing v4l2_ctrl_handler_free(), and allresources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()are leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53644 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: radio-shark: Add endpoint checksThe syzbot fuzzer was able to provoke a WARNING from the radio-shark2driver:------------[ cut here ]------------usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 3271 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Modules linked in:CPU: 0 PID: 3271 Comm: kworker/0:3 Not tainted 6.1.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x1880 drivers/usb/core/urb.c:504Code: 7c 24 18 e8 00 36 ea fb 48 8b 7c 24 18 e8 36 1c 02 ff 41 89 d8 44 89 e1 4c 89 ea 48 89 c6 48 c7 c7 a0 b6 90 8a e8 9a 29 b8 03 <0f> 0b e9 58 f8 ff ff e8 d2 35 ea fb 48 81 c5 c0 05 00 00 e9 84 f7RSP: 0018:ffffc90003876dd0 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000RDX: ffff8880750b0040 RSI: ffffffff816152b8 RDI: fffff5200070edacRBP: ffff8880172d81e0 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000000 R12: 0000000000000001R13: ffff8880285c5040 R14: 0000000000000002 R15: ffff888017158200FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe03235b90 CR3: 000000000bc8e000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58 usb_bulk_msg+0x226/0x550 drivers/usb/core/message.c:387 shark_write_reg+0x1ff/0x2e0 drivers/media/radio/radio-shark2.c:88...The problem was caused by the fact that the driver does not checkwhether the endpoints it uses are actually present and have theappropriate types. This can be fixed by adding a simple check ofthese endpoints (and similarly for the radio-shark driver).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53647 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't dereference ACPI root object handleSince the commit referenced in the Fixes: tag below the VMBus client driveris walking the ACPI namespace up from the VMBus ACPI device to the ACPInamespace root object trying to find Hyper-V MMIO ranges.However, if it is not able to find them it ends trying to walk resources ofthe ACPI namespace root object itself.This object has all-ones handle, which causes a NULL pointer dereferencein the ACPI code (from dereferencing this pointer with an offset).This in turn causes an oops on boot with VMBus host implementations that donot provide Hyper-V MMIO ranges in their VMBus ACPI device or itsancestors.The QEMU VMBus implementation is an example of such implementation.I guess providing these ranges is optional, since all tested Windowsversions seem to be able to use VMBus devices without them.Fix this by explicitly terminating the lookup at the ACPI namespace rootobject.Note that Linux guests under KVM/QEMU do not use the Hyper-V PV interfaceby default - they only do so if the KVM PV interface is missing ordisabled.Example stack trace of such oops:[ 3.710827] ? __die+0x1f/0x60[ 3.715030] ? page_fault_oops+0x159/0x460[ 3.716008] ? exc_page_fault+0x73/0x170[ 3.716959] ? asm_exc_page_fault+0x22/0x30[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0[ 3.723559] ? down_timeout+0x3a/0x60[ 3.724455] ? acpi_ns_get_node+0x3a/0x60[ 3.725412] acpi_ns_get_node+0x3a/0x60[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0[ 3.728400] acpi_rs_get_method_data+0x2b/0x70[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus][ 3.732411] acpi_walk_resources+0x78/0xd0[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus][ 3.734802] platform_probe+0x3d/0x90[ 3.735684] really_probe+0x19b/0x400[ 3.736570] ? __device_attach_driver+0x100/0x100[ 3.737697] __driver_probe_device+0x78/0x160[ 3.738746] driver_probe_device+0x1f/0x90[ 3.739743] __driver_attach+0xc2/0x1b0[ 3.740671] bus_for_each_dev+0x70/0xc0[ 3.741601] bus_add_driver+0x10e/0x210[ 3.742527] driver_register+0x55/0xf0[ 3.744412] ? 0xffffffffc039a000[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53648 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: ac97: Fix possible NULL dereference in snd_ac97_mixersmatch error:sound/pci/ac97/ac97_codec.c:2354 snd_ac97_mixer() error:we previously assumed 'rac97' could be null (see line 2072)remove redundant assignment, return error if rac97 is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53657 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't tx before switchdev is fully configuredThere is possibility that ice_eswitch_port_start_xmit might becalled while some resources are still not allocated which mightcause NULL pointer dereference. Fix this by checking if switchdevconfiguration was finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: bcm-qspi: return error if neither hif_mspi nor mspi is availableIf neither a "hif_mspi" nor "mspi" resource is present, the driver willjust early exit in probe but still return success. Apart from not doinganything meaningful, this would then also lead to a null pointer accesson removal, as platform_get_drvdata() would return NULL, which it wouldthen try to dereference when trying to unregister the spi master.Fix this by unconditionally calling devm_ioremap_resource(), as it canhandle a NULL res and will then return a viable ERR_PTR() if we get one.The "return 0;" was previously a "goto qspi_resource_err;" where thenret was returned, but since ret was still initialized to 0 at this placethis was a valid conversion in 63c5395bb7a9 ("spi: bcm-qspi: Fixuse-after-free on unbind"). The issue was not introduced by this commit,only made more obvious.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53672 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: output extra debug info if we failed to find an inline backref[BUG]Syzbot reported several warning triggered insidelookup_inline_extent_backref().[CAUSE]As usual, the reproducer doesn't reliably trigger locally here, but atleast we know the WARN_ON() is triggered when an inline backref can notbe found, and it can only be triggered when @insert is true. (I.e.inserting a new inline backref, which means the backref should alreadyexist)[ENHANCEMENT]After the WARN_ON(), dump all the parameters and the extent treeleaf to help debug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible desc_ptr out-of-bounds accessesSanitize possible desc_ptr out-of-bounds accesses inses_enclosure_data_process().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt7601u: fix an integer underflowFix an integer underflow that leads to a null pointer dereference in'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packetcould be manipulated, which could trigger an integer underflow of'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequentlycauses the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to bebypassed, eventually leading to a dereference of the pointer 'p', whichis a null pointer.Ensure that 'dma_len' is greater than 'min_seg_len'.Found by a modified version of syzkaller.KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+#139Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014RIP: 0010:skb_add_rx_frag+0x143/0x370Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 4489 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 0200 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008FS: 0000000000000000(0000) GS:ffff88811a800000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: mt7601u_rx_tasklet+0xc73/0x1270 ? mt7601u_submit_rx_buf.isra.0+0x510/0x510 ? tasklet_action_common.isra.0+0x79/0x2f0 tasklet_action_common.isra.0+0x206/0x2f0 __do_softirq+0x1b5/0x880 ? tasklet_unlock+0x30/0x30 run_ksoftirqd+0x26/0x50 smpboot_thread_fn+0x34f/0x7d0 ? smpboot_register_percpu_thread+0x370/0x370 kthread+0x3a1/0x480 ? set_kthread_struct+0x120/0x120 ret_from_fork+0x1f/0x30Modules linked in: 88XXau(O) 88x2bu(O)---[ end trace 57f34f93b4da0f9b ]---RIP: 0010:skb_add_rx_frag+0x143/0x370Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 4489 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 0200 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008FS: 0000000000000000(0000) GS:ffff88811a800000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Avoid calling OPDESC() with ops->opnum == OP_ILLEGALOPDESC() simply indexes into nfsd4_ops[] by the op's operationnumber, without range checking that value. It assumes callers arecareful to avoid calling it with an out-of-bounds opnum value.nfsd4_decode_compound() is not so careful, and can invoke OPDESC()with opnum set to OP_ILLEGAL, which is 10044 -- well beyond the endof nfsd4_ops[].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Zero padding when dumping algos and encapWhen copying data to user-space we should ensure that only validdata is copied over. Padding in structures may be filled withrandom (possibly sensitve) data and should never be given directlyto user-space.This patch fixes the copying of xfrm algorithms and the encaptemplate in xfrm_user so that padding is zeroed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix use-after-free read in ext4_find_extent for bigalloc + inlineSyzbot found the following issue:loop0: detected capacity change from 0 to 2048EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.==================================================================BUG: KASAN: use-after-free in ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline]BUG: KASAN: use-after-free in ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931Read of size 4 at addr ffff888073644750 by task syz-executor420/5067CPU: 0 PID: 5067 Comm: syz-executor420 Not tainted 6.2.0-rc1-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x1b1/0x290 lib/dump_stack.c:106 print_address_description+0x74/0x340 mm/kasan/report.c:306 print_report+0x107/0x1f0 mm/kasan/report.c:417 kasan_report+0xcd/0x100 mm/kasan/report.c:517 ext4_ext_binsearch_idx fs/ext4/extents.c:768 [inline] ext4_find_extent+0x76e/0xd90 fs/ext4/extents.c:931 ext4_clu_mapped+0x117/0x970 fs/ext4/extents.c:5809 ext4_insert_delayed_block fs/ext4/inode.c:1696 [inline] ext4_da_map_blocks fs/ext4/inode.c:1806 [inline] ext4_da_get_block_prep+0x9e8/0x13c0 fs/ext4/inode.c:1870 ext4_block_write_begin+0x6a8/0x2290 fs/ext4/inode.c:1098 ext4_da_write_begin+0x539/0x760 fs/ext4/inode.c:3082 generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772 ext4_buffered_write_iter+0x122/0x3a0 fs/ext4/file.c:285 ext4_file_write_iter+0x1d0/0x18f0 call_write_iter include/linux/fs.h:2186 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x7dc/0xc50 fs/read_write.c:584 ksys_write+0x177/0x2a0 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f4b7a9737b9RSP: 002b:00007ffc5cac3668 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f4b7a9737b9RDX: 00000000175d9003 RSI: 0000000020000200 RDI: 0000000000000004RBP: 00007f4b7a933050 R08: 0000000000000000 R09: 0000000000000000R10: 000000000000079f R11: 0000000000000246 R12: 00007f4b7a9330e0R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Above issue is happens when enable bigalloc and inline data feature. Ascommit 131294c35ed6 fixed delayed allocation bug in ext4_clu_mapped forbigalloc + inline. But it only resolved issue when has inline data, ifinline data has been converted to extent(ext4_da_convert_inline_data_to_extent)before writepages, there is no EXT4_STATE_MAY_INLINE_DATA flag. Howeveri_data is still store inline data in this scene. Then will trigger UAFwhen find extent.To resolve above issue, there is need to add judge "ext4_has_inline_data(inode)"in ext4_clu_mapped().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: Fix the memory leak in raw_gadget driverCurrently, increasing raw_dev->count happens before invoke theraw_queue_event(), if the raw_queue_event() return error, invokeraw_release() will not trigger the dev_free() to be called.[ 268.905865][ T5067] raw-gadget.0 gadget.0: failed to queue event[ 268.912053][ T5067] udc dummy_udc.0: failed to start USB Raw Gadget: -12[ 268.918885][ T5067] raw-gadget.0: probe of gadget.0 failed with error -12[ 268.925956][ T5067] UDC core: USB Raw Gadget: couldn't find an available UDC or it's busy[ 268.934657][ T5067] misc raw-gadget: fail, usb_gadget_register_driver returned -16BUG: memory leak[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dev_new drivers/usb/gadget/legacy/raw_gadget.c:191 [inline][] raw_open+0x45/0x110 drivers/usb/gadget/legacy/raw_gadget.c:385[] misc_open+0x1a9/0x1f0 drivers/char/misc.c:165[] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] raw_ioctl_init+0xdf/0x410 drivers/usb/gadget/legacy/raw_gadget.c:460[] raw_ioctl+0x5f9/0x1120 drivers/usb/gadget/legacy/raw_gadget.c:1250[] vfs_ioctl fs/ioctl.c:51 [inline][] kmalloc_trace+0x24/0x90 mm/slab_common.c:1076[] kmalloc include/linux/slab.h:582 [inline][] kzalloc include/linux/slab.h:703 [inline][] dummy_alloc_request+0x5a/0xe0 drivers/usb/gadget/udc/dummy_hcd.c:665[] usb_ep_alloc_request+0x22/0xd0 drivers/usb/gadget/udc/core.c:196[] gadget_bind+0x6d/0x370 drivers/usb/gadget/legacy/raw_gadget.c:292This commit therefore invoke kref_get() under the condition thatraw_queue_event() return success.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix memory leak in qla2x00_probe_one()There is a memory leak reported by kmemleak: unreferenced object 0xffffc900003f0000 (size 12288): comm "modprobe", pid 19117, jiffies 4299751452 (age 42490.264s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000629261a8>] __vmalloc_node_range+0xe56/0x1110 [<0000000001906886>] __vmalloc_node+0xbd/0x150 [<000000005bb4dc34>] vmalloc+0x25/0x30 [<00000000a2dc1194>] qla2x00_create_host+0x7a0/0xe30 [qla2xxx] [<0000000062b14b47>] qla2x00_probe_one+0x2eb8/0xd160 [qla2xxx] [<00000000641ccc04>] local_pci_probe+0xeb/0x1a0The root cause is traced to an error-handling path in qla2x00_probe_one()when the adapter "base_vha" initialize failed. The fab_scan_rp "scan.l" isused to record the port information and it is allocated inqla2x00_create_host(). However, it is not released in the error handlingpath "probe_failed".Fix this by freeing the memory of "scan.l" when an error occurs in theadapter initialization process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53700 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: max9286: Fix memleak in max9286_v4l2_register()There is a kmemleak when testing the media/i2c/max9286.c with bpf mockdevice:kmemleak: 5 new suspected memory leaks (see /sys/kernel/debug/kmemleak)unreferenced object 0xffff88810defc400 (size 256): comm "python3", pid 278, jiffies 4294737563 (age 31.978s) hex dump (first 32 bytes): 28 06 a7 0a 81 88 ff ff 00 fe 22 12 81 88 ff ff (........."..... 10 c4 ef 0d 81 88 ff ff 10 c4 ef 0d 81 88 ff ff ................ backtrace: [<00000000191de6a7>] __kmalloc_node+0x44/0x1b0 [<000000002f4912b7>] kvmalloc_node+0x34/0x180 [<0000000057dc4cae>] v4l2_ctrl_new+0x325/0x10f0 [videodev] [<0000000026030272>] v4l2_ctrl_new_std+0x16f/0x210 [videodev] [<00000000f0d9ea2f>] max9286_probe+0x76e/0xbff [max9286] [<00000000ea8f6455>] i2c_device_probe+0x28d/0x680 [<0000000087529af3>] really_probe+0x17c/0x3f0 [<00000000b08be526>] __driver_probe_device+0xe3/0x170 [<000000004382edea>] driver_probe_device+0x49/0x120 [<000000007bde528a>] __device_attach_driver+0xf7/0x150 [<000000009f9c6ab4>] bus_for_each_drv+0x114/0x180 [<00000000c8aaf588>] __device_attach+0x1e5/0x2d0 [<0000000041cc06b9>] bus_probe_device+0x126/0x140 [<000000002309860d>] device_add+0x810/0x1130 [<000000002827bf98>] i2c_new_client_device+0x359/0x4f0 [<00000000593bdc85>] of_i2c_register_device+0xf1/0x110max9286_v4l2_register() calls v4l2_ctrl_new_std(), but won't free thecreated v412_ctrl when fwnode_graph_get_endpoint_by_id() failed, whichcauses the memleak. Call v4l2_ctrl_handler_free() to free the v412_ctrl.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Handle race between rb_move_tail and rb_check_pagesIt seems a data race between ring_buffer writing and integrity check.That is, RB_FLAG of head_page is been updating, while at same timeRB_FLAG was cleared when doing integrity check rb_check_pages(): rb_check_pages() rb_handle_head_page(): -------- -------- rb_head_page_deactivate() rb_head_page_set_normal() rb_head_page_activate()We do intergrity test of the list to check if the list is corrupted andit is still worth doing it. So, let's refactor rb_check_pages() such thatwe no longer clear and set flag during the list sanity checking.[1] and [2] are the test to reproduce and the crash report respectively.1:``` read_trace.sh while true; do # the "trace" file is closed after read head -1 /sys/kernel/tracing/trace > /dev/null done`````` repro.sh sysctl -w kernel.panic_on_warn=1 # function tracer will writing enough data into ring_buffer echo function > /sys/kernel/tracing/current_tracer ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh & ./read_trace.sh &```2:------------[ cut here ]------------WARNING: CPU: 9 PID: 62 at kernel/trace/ring_buffer.c:2653rb_move_tail+0x450/0x470Modules linked in:CPU: 9 PID: 62 Comm: ksoftirqd/9 Tainted: G W 6.2.0-rc6+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014RIP: 0010:rb_move_tail+0x450/0x470Code: ff ff 4c 89 c8 f0 4d 0f b1 02 48 89 c2 48 83 e2 fc 49 39 d0 75 2483 e0 03 83 f8 02 0f 84 e1 fb ff ff 48 8b 57 10 f0 ff 42 08 <0f> 0b 83f8 02 0f 84 ce fb ff ff e9 dbRSP: 0018:ffffb5564089bd00 EFLAGS: 00000203RAX: 0000000000000000 RBX: ffff9db385a2bf81 RCX: ffffb5564089bd18RDX: ffff9db281110100 RSI: 0000000000000fe4 RDI: ffff9db380145400RBP: ffff9db385a2bf80 R08: ffff9db385a2bfc0 R09: ffff9db385a2bfc2R10: ffff9db385a6c000 R11: ffff9db385a2bf80 R12: 0000000000000000R13: 00000000000003e8 R14: ffff9db281110100 R15: ffffffffbb006108FS: 0000000000000000(0000) GS:ffff9db3bdcc0000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005602323024c8 CR3: 0000000022e0c000 CR4: 00000000000006e0Call Trace: ring_buffer_lock_reserve+0x136/0x360 ? __do_softirq+0x287/0x2df ? __pfx_rcu_softirq_qs+0x10/0x10 trace_function+0x21/0x110 ? __pfx_rcu_softirq_qs+0x10/0x10 ? __do_softirq+0x287/0x2df function_trace_call+0xf6/0x120 0xffffffffc038f097 ? rcu_softirq_qs+0x5/0x140 rcu_softirq_qs+0x5/0x140 __do_softirq+0x287/0x2df run_ksoftirqd+0x2a/0x30 smpboot_thread_fn+0x188/0x220 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0xe7/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ---[ end trace 0000000000000000 ]---[ crash report and test reproducer credit goes to Zheng Yejian]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53726 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: csum: Fix OoB access in IP checksum code for negative lengthsAlthough commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-lengthcalls") added an early return for zero-length input, syzkaller haspopped up with an example of a _negative_ length which causes anundefined shift and an out-of-bounds read: | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975 | | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023 | Call trace: | dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 | show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 | __dump_stack lib/dump_stack.c:88 [inline] | dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 | print_address_description mm/kasan/report.c:351 [inline] | print_report+0x174/0x514 mm/kasan/report.c:462 | kasan_report+0xd4/0x130 mm/kasan/report.c:572 | kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 | __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31 | do_csum+0x44/0x254 arch/arm64/lib/csum.c:39 | csum_partial+0x30/0x58 lib/checksum.c:128 | gso_make_checksum include/linux/skbuff.h:4928 [inline] | __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332 | udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47 | ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119 | skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141 | __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401 | skb_gso_segment include/linux/netdevice.h:4859 [inline] | validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659 | validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709 | sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327 | __dev_xmit_skb net/core/dev.c:3805 [inline] | __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210 | dev_queue_xmit include/linux/netdevice.h:3085 [inline] | packet_xmit+0x6c/0x318 net/packet/af_packet.c:276 | packet_snd net/packet/af_packet.c:3081 [inline] | packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113 | sock_sendmsg_nosec net/socket.c:724 [inline] | sock_sendmsg net/socket.c:747 [inline] | __sys_sendto+0x3b4/0x538 net/socket.c:2144Extend the early return to reject negative lengths as well, aligning ourimplementation with the generic code in lib/checksum.c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: fq_pie: avoid stalls in fq_pie_timer()When setting a high number of flows (limit being 65536),fq_pie_timer() is currently using too much time as syzbot reported.Add logic to yield the cpu every 2048 flows (less than 150 usecon debug kernels).It should also help by not blocking qdisc fast paths for too long.Worst case (65536 flows) would need 31 jiffies for a complete scan.Relevant extract from syzbot report:rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.rcu: blocking rcu_node structures (internal RCU debug):Sending NMI from CPU 1 to CPUs 0:NMI backtrace for cpu 0CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8bRSP: 0018:ffffc90000007bb8 EFLAGS: 00000206RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: vector: Fix memory leak in vector_configIf the return value of the uml_parse_vector_ifspec function is NULL,we should call kfree(params) to prevent memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Fix potential array out-of-bounds in decoder queue_setupvariable *nplanes is provided by user via system call argument. Thepossible value of q_data->fmt->num_planes is 1-3, while the valueof *nplanes can be 1-8. The array access by index i can cause arrayout-of-bounds.Fix this bug by checking *nplanes against the array size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix mapping to non-allocated address[Why]There is an issue mapping non-allocated location of memory.It would allocate gpio registers from an array out of bounds.[How]Patch correct numbers of bounds for using.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/irq-mvebu-gicp: Fix refcount leak in mvebu_gicp_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53769 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virt/coco/sev-guest: Double-buffer messagesThe encryption algorithms read and write directly to shared unencryptedmemory, which may leak information as well as permit the host to tamperwith the message integrity. Instead, copy whole messages in or out asneeded before doing any computation on them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53785 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7921: don't assume adequate headroom for SDIO headersmt7921_usb_sdio_tx_prepare_skb() calls mt7921_usb_sdio_write_txwi() andmt7921_skb_add_usb_sdio_hdr(), both of which blindly assume thatadequate headroom will be available in the passed skb. This assumptiontypically is satisfied when the skb was allocated in the net core fortransmission via the mt7921 netdev (although even that is only anoptimization and is not strictly guaranteed), but the assumption issometimes not satisfied when the skb originated in the receive path ofanother netdev and was passed through to the mt7921, such as by thebridge layer. Blindly prepending bytes to an skb is always wrong.This commit introduces a call to skb_cow_head() before the call tomt7921_usb_sdio_write_txwi() in mt7921_usb_sdio_tx_prepare_skb() toensure that at least MT_SDIO_TXD_SIZE + MT_SDIO_HDR_SIZE bytes can bepushed onto the skb.Without this fix, I can trivially cause kernel panics by bridging anMT7921AU-based USB 802.11ax interface with an Ethernet interface on anIntel Atom-based x86 system using its onboard RTL8169 PCI Ethernetadapter and also on an ARM-based Raspberry Pi 1 using its onboardSMSC9512 USB Ethernet adapter. Note that the panics do not occur inevery system configuration, as they occur only if the receiving netdevleaves less headroom in its received skbs than the mt7921 needs for itsSDIO headers.Here is an example stack trace of this panic on Raspberry Pi OS Lite2023-02-21 running kernel 6.1.24+ [1]: skb_panic from skb_push+0x44/0x48 skb_push from mt7921_usb_sdio_tx_prepare_skb+0xd4/0x190 [mt7921_common] mt7921_usb_sdio_tx_prepare_skb [mt7921_common] from mt76u_tx_queue_skb+0x94/0x1d0 [mt76_usb] mt76u_tx_queue_skb [mt76_usb] from __mt76_tx_queue_skb+0x4c/0xc8 [mt76] __mt76_tx_queue_skb [mt76] from mt76_txq_schedule.part.0+0x13c/0x398 [mt76] mt76_txq_schedule.part.0 [mt76] from mt76_txq_schedule_all+0x24/0x30 [mt76] mt76_txq_schedule_all [mt76] from mt7921_tx_worker+0x58/0xf4 [mt7921_common] mt7921_tx_worker [mt7921_common] from __mt76_worker_fn+0x9c/0xec [mt76] __mt76_worker_fn [mt76] from kthread+0xbc/0xe0 kthread from ret_from_fork+0x14/0x34After this fix, bridging the mt7921 interface works fine on both of mypreviously problematic systems.[1] https://github.com/raspberrypi/firmware/tree/5c276f55a4b21345cd4d6200a504ee991851ff7a

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: Fix uninitialized number of lanesIt is not possible to set the number of lanes when setting link modesusing the legacy IOCTL ethtool interface. Since 'structethtool_link_ksettings' is not initialized in this path, drivers receivean uninitialized number of lanes in 'structethtool_link_ksettings::lanes'.When this information is later queried from drivers, it results in theethtool code making decisions based on uninitialized memory, leading tothe following KMSAN splat [1]. In practice, this most likely onlyhappens with the tun driver that simply returns whatever it got in theset operation.As far as I can tell, this uninitialized memory is not leaked to userspace thanks to the 'ethtool_ops->cap_link_lanes_supported' check inlinkmodes_prepare_data().Fix by initializing the structure in the IOCTL path. Did not find anymore call sites that pass an uninitialized structure when calling'ethtool_ops::set_link_ksettings()'.[1]BUG: KMSAN: uninit-value in ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline]BUG: KMSAN: uninit-value in ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_update_linkmodes net/ethtool/linkmodes.c:273 [inline] ethnl_set_linkmodes+0x190b/0x19d0 net/ethtool/linkmodes.c:333 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_get_link_ksettings+0x37/0x60 drivers/net/tun.c:3544 __ethtool_get_link_ksettings+0x17b/0x260 net/ethtool/ioctl.c:441 ethnl_set_linkmodes+0xee/0x19d0 net/ethtool/linkmodes.c:327 ethnl_default_set_doit+0x88d/0xde0 net/ethtool/netlink.c:640 genl_family_rcv_msg_doit net/netlink/genetlink.c:968 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1048 [inline] genl_rcv_msg+0x141a/0x14c0 net/netlink/genetlink.c:1065 netlink_rcv_skb+0x3f8/0x750 net/netlink/af_netlink.c:2577 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1076 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0xf41/0x1270 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x127d/0x1430 net/netlink/af_netlink.c:1942 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg net/socket.c:747 [inline] ____sys_sendmsg+0xa24/0xe40 net/socket.c:2501 ___sys_sendmsg+0x2a1/0x3f0 net/socket.c:2555 __sys_sendmsg net/socket.c:2584 [inline] __do_sys_sendmsg net/socket.c:2593 [inline] __se_sys_sendmsg net/socket.c:2591 [inline] __x64_sys_sendmsg+0x36b/0x540 net/socket.c:2591 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at: tun_set_link_ksettings+0x37/0x60 drivers/net/tun.c:3553 ethtool_set_link_ksettings+0x600/0x690 net/ethtool/ioctl.c:609 __dev_ethtool net/ethtool/ioctl.c:3024 [inline] dev_ethtool+0x1db9/0x2a70 net/ethtool/ioctl.c:3078 dev_ioctl+0xb07/0x1270 net/core/dev_ioctl.c:524 sock_do_ioctl+0x295/0x540 net/socket.c:1213 sock_i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53799 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: api - Use work queue in crypto_destroy_instanceThe function crypto_drop_spawn expects to be called in processcontext. However, when an instance is unregistered while it stillhas active users, the last user may cause the instance to be freedin atomic context.Fix this by delaying the freeing to a work queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/sprd: Release dma buffer to avoid memory leakWhen attaching to a domain, the driver would alloc a DMA buffer whichis used to store address mapping table, and it need to be releasedwhen the IOMMU domain is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: clocking-wizard: Fix Oops in clk_wzrd_register_divider()Smatch detected this potential error pointer dereferenceclk_wzrd_register_divider(). If devm_clk_hw_register() fails thenit sets "hw" to an error pointer and then dereferences it on thenext line. Return the error directly instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: release crypto keyslot before reporting I/O completeOnce all I/O using a blk_crypto_key has completed, filesystems can callblk_crypto_evict_key(). However, the block layer currently doesn't callblk_crypto_put_keyslot() until the request is being freed, which happensafter upper layers have been told (via bio_endio()) the I/O hascompleted. This causes a race condition where blk_crypto_evict_key()can see 'slot_refs != 0' without there being an actual bug.This makes __blk_crypto_evict_key() hit the'WARN_ON_ONCE(atomic_read(&slot->slot_refs) != 0)' and return withoutdoing anything, eventually causing a use-after-free inblk_crypto_reprogram_all_keys(). (This is a very rare bug and has onlybeen seen when per-file keys are being used with fscrypt.)There are two options to fix this: either release the keyslot beforebio_endio() is called on the request's last bio, or make__blk_crypto_evict_key() ignore slot_refs. Let's go with the firstsolution, since it preserves the ability to report bugs (viaWARN_ON_ONCE) where a key is evicted while still in-use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53815 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Prevent RT livelock in itimer_delete()itimer_delete() has a retry loop when the timer is concurrently expired. Onnon-RT kernels this just spin-waits until the timer callback has completed,except for posix CPU timers which have HAVE_POSIX_CPU_TIMERS_TASK_WORKenabled.In that case and on RT kernels the existing task could live lock whenpreempting the task which does the timer delivery.Replace spin_unlock() with an invocation of timer_wait_running() to handleit the same way as the other retry loops in the posix timer code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - avoid null pointer deref in mpi_cmp_ui()During NVMeTCP Authentication a controller can trigger a kerneloops by specifying the 8192 bit Diffie Hellman group and passinga correctly sized, but zeroed Diffie Hellamn value.mpi_cmp_ui() was detecting this if the second parameter was 0,but 1 is passed from dh_is_pubkey_valid(). This causes the nullpointer u->d to be dereferenced towards the end of mpi_cmp_ui()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Ignore frags from uninitialized peer in dp.When max virtual ap interfaces are configured in all the bands withACS and hostapd restart is done every 60s, a crash is observed atrandom times.In this certain scenario, a fragmented packet is received forself peer, for which rx_tid and rx_frags are not initialized indatapath. While handling this fragment, crash is observed as therx_frag list is uninitialised and when we walk inath11k_dp_rx_h_sort_frags, skb null leads to exception.To address this, before processing received fragments we checkdp_setup_done flag is set to ensure that peer has completed itsdp peer setup for fragment queue, else ignore processing thefragments.Call trace: ath11k_dp_process_rx_err+0x550/0x1084 [ath11k] ath11k_dp_service_srng+0x70/0x370 [ath11k] 0xffffffc009693a04 __napi_poll+0x30/0xa4 net_rx_action+0x118/0x270 __do_softirq+0x10c/0x244 irq_exit+0x64/0xb4 __handle_domain_irq+0x88/0xac gic_handle_irq+0x74/0xbc el1_irq+0xf0/0x1c0 arch_cpu_idle+0x10/0x18 do_idle+0x104/0x248 cpu_startup_entry+0x20/0x64 rest_init+0xd0/0xdc arch_call_rest_init+0xc/0x14 start_kernel+0x480/0x4b8 Code: f9400281 f94066a2 91405021 b94a0023 (f9406401)Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate lockless accesses to nlk->max_recvmsg_lensyzbot reported a data-race in data-race in netlink_recvmsg() [1]Indeed, netlink_recvmsg() can be run concurrently,and netlink_dump() also needs protection.[1]BUG: KCSAN: data-race in netlink_recvmsg / netlink_recvmsgread to 0xffff888141840b38 of 8 bytes by task 23057 on cpu 0:netlink_recvmsg+0xea/0x730 net/netlink/af_netlink.c:1988sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]__sys_recvfrom+0x1ee/0x2e0 net/socket.c:2194__do_sys_recvfrom net/socket.c:2212 [inline]__se_sys_recvfrom net/socket.c:2208 [inline]__x64_sys_recvfrom+0x78/0x90 net/socket.c:2208do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdwrite to 0xffff888141840b38 of 8 bytes by task 23037 on cpu 1:netlink_recvmsg+0x114/0x730 net/netlink/af_netlink.c:1989sock_recvmsg_nosec net/socket.c:1017 [inline]sock_recvmsg net/socket.c:1038 [inline]____sys_recvmsg+0x156/0x310 net/socket.c:2720___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -> 0x0000000000001000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 23037 Comm: syz-executor.2 Not tainted 6.3.0-rc4-syzkaller-00195-g5a57b48fdfcb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix error handling for SOCK_DGRAM in kcm_sendmsg().syzkaller found a memory leak in kcm_sendmsg(), and commit c821a88bd720("kcm: Fix memory leak in error path of kcm_sendmsg()") suppressed it byupdating kcm_tx_msg(head)->last_skb if partial data is copied so that thefollowing sendmsg() will resume from the skb.However, we cannot know how many bytes were copied when we get the error.Thus, we could mess up the MSG_MORE queue.When kcm_sendmsg() fails for SOCK_DGRAM, we should purge the queue as wedo so for UDP by udp_flush_pending_frames().Even without this change, when the error occurred, the following sendmsg()resumed from a wrong skb and the queue was messed up. However, we haveyet to get such a report, and only syzkaller stumbled on it. So, thiscan be changed safely.Note this does not change SOCK_SEQPACKET behaviour.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: read sk->sk_family once in sk_mc_loop()syzbot is playing with IPV6_ADDRFORM quite a lot these days,and managed to hit the WARN_ON_ONCE(1) in sk_mc_loop()We have many more similar issues to fix.WARNING: CPU: 1 PID: 1593 at net/core/sock.c:782 sk_mc_loop+0x165/0x260Modules linked in:CPU: 1 PID: 1593 Comm: kworker/1:3 Not tainted 6.1.40-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023Workqueue: events_power_efficient gc_workerRIP: 0010:sk_mc_loop+0x165/0x260 net/core/sock.c:782Code: 34 1b fd 49 81 c7 18 05 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 20 00 74 08 4c 89 ff e8 25 36 6d fd 4d 8b 37 eb 13 e8 db 33 1b fd <0f> 0b b3 01 eb 34 e8 d0 33 1b fd 45 31 f6 49 83 c6 38 4c 89 f0 48RSP: 0018:ffffc90000388530 EFLAGS: 00010246RAX: ffffffff846d9b55 RBX: 0000000000000011 RCX: ffff88814f884980RDX: 0000000000000102 RSI: ffffffff87ae5160 RDI: 0000000000000011RBP: ffffc90000388550 R08: 0000000000000003 R09: ffffffff846d9a65R10: 0000000000000002 R11: ffff88814f884980 R12: dffffc0000000000R13: ffff88810dbee000 R14: 0000000000000010 R15: ffff888150084000FS: 0000000000000000(0000) GS:ffff8881f6b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000180 CR3: 000000014ee5b000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:[] ip6_finish_output2+0x33f/0x1ae0 net/ipv6/ip6_output.c:83[] __ip6_finish_output net/ipv6/ip6_output.c:200 [inline][] ip6_finish_output+0x6c6/0xb10 net/ipv6/ip6_output.c:211[] NF_HOOK_COND include/linux/netfilter.h:298 [inline][] ip6_output+0x2bc/0x3d0 net/ipv6/ip6_output.c:232[] dst_output include/net/dst.h:444 [inline][] ip6_local_out+0x10f/0x140 net/ipv6/output_core.c:161[] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:483 [inline][] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline][] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline][] ipvlan_queue_xmit+0x1174/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677[] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229[] netdev_start_xmit include/linux/netdevice.h:4925 [inline][] xmit_one net/core/dev.c:3644 [inline][] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660[] sch_direct_xmit+0x2a0/0x9c0 net/sched/sch_generic.c:342[] qdisc_restart net/sched/sch_generic.c:407 [inline][] __qdisc_run+0xb13/0x1e70 net/sched/sch_generic.c:415[] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125[] net_tx_action+0x7ac/0x940 net/core/dev.c:5247[] __do_softirq+0x2bd/0x9bd kernel/softirq.c:599[] invoke_softirq kernel/softirq.c:430 [inline][] __irq_exit_rcu+0xc8/0x170 kernel/softirq.c:683[] irq_exit_rcu+0x9/0x20 kernel/softirq.c:695

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Fix skb refcnt race after locking changesThere is a race where skb's from the sk_psock_backlog can be referencedafter userspace side has already skb_consumed() the sk_buff and its refcntdropped to zer0 causing use after free.The flow is the following: while ((skb = skb_peek(&psock->ingress_skb)) sk_psock_handle_Skb(psock, skb, ..., ingress) if (!ingress) ... sk_psock_skb_ingress sk_psock_skb_ingress_enqueue(skb) msg->skb = skb sk_psock_queue_msg(psock, msg) skb_dequeue(&psock->ingress_skb)The sk_psock_queue_msg() puts the msg on the ingress_msg queue. This iswhat the application reads when recvmsg() is called. An application canread this anytime after the msg is placed on the queue. The recvmsg hookwill also read msg->skb and then after user space reads the msg will callconsume_skb(skb) on it effectively free'ing it.But, the race is in above where backlog queue still has a reference tothe skb and calls skb_dequeue(). If the skb_dequeue happens after theuser reads and free's the skb we have a use after free.The !ingress case does not suffer from this problem because it usessendmsg_*(sk, msg) which does not pass the sk_buff further down thestack.The following splat was observed with 'test_progs -t sockmap_listen': [ 1022.710250][ T2556] general protection fault, ... [...] [ 1022.712830][ T2556] Workqueue: events sk_psock_backlog [ 1022.713262][ T2556] RIP: 0010:skb_dequeue+0x4c/0x80 [ 1022.713653][ T2556] Code: ... [...] [ 1022.720699][ T2556] Call Trace: [ 1022.720984][ T2556] [ 1022.721254][ T2556] ? die_addr+0x32/0x80^M [ 1022.721589][ T2556] ? exc_general_protection+0x25a/0x4b0 [ 1022.722026][ T2556] ? asm_exc_general_protection+0x22/0x30 [ 1022.722489][ T2556] ? skb_dequeue+0x4c/0x80 [ 1022.722854][ T2556] sk_psock_backlog+0x27a/0x300 [ 1022.723243][ T2556] process_one_work+0x2a7/0x5b0 [ 1022.723633][ T2556] worker_thread+0x4f/0x3a0 [ 1022.723998][ T2556] ? __pfx_worker_thread+0x10/0x10 [ 1022.724386][ T2556] kthread+0xfd/0x130 [ 1022.724709][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725066][ T2556] ret_from_fork+0x2d/0x50 [ 1022.725409][ T2556] ? __pfx_kthread+0x10/0x10 [ 1022.725799][ T2556] ret_from_fork_asm+0x1b/0x30 [ 1022.726201][ T2556] To fix we add an skb_get() before passing the skb to be enqueued in theengress queue. This bumps the skb->users refcnt so that consume_skb()and kfree_skb will not immediately free the sk_buff. With this we canbe sure the skb is still around when we do the dequeue. Then we justneed to decrement the refcnt or free the skb in the backlog case whichwe do by calling kfree_skb() on the ingress case as well as the sendmsgcase.Before locking change from fixes tag we had the sock locked so wecouldn't race with user and there was no issue here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53846 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on direct node in truncate_dnode()syzbot reports below bug:BUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574Read of size 4 at addr ffff88802a25c000 by task syz-executor148/5000CPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106 print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351 print_report mm/kasan/report.c:462 [inline] kasan_report+0x11c/0x130 mm/kasan/report.c:572 f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574 truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944 f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154 f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721 f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749 f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799 f2fs_truncate include/linux/fs.h:825 [inline] f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006 notify_change+0xb2c/0x1180 fs/attr.c:483 do_truncate+0x143/0x200 fs/open.c:66 handle_truncate fs/namei.c:3295 [inline] do_open fs/namei.c:3640 [inline] path_openat+0x2083/0x2750 fs/namei.c:3791 do_filp_open+0x1ba/0x410 fs/namei.c:3818 do_sys_openat2+0x16d/0x4c0 fs/open.c:1356 do_sys_open fs/open.c:1372 [inline] __do_sys_creat fs/open.c:1448 [inline] __se_sys_creat fs/open.c:1442 [inline] __x64_sys_creat+0xcd/0x120 fs/open.c:1442 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root cause is, inodeA references inodeB via inodeB's ino, once inodeAis truncated, it calls truncate_dnode() to truncate data blocks in inodeB'snode page, it traverse mapping data from node->i.i_addr[0] tonode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.This patch fixes to add sanity check on dnode page in truncate_dnode(),so that, it can help to avoid triggering such issue, and once it encounterssuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCEerror into superblock, later fsck can detect such issue and try repairing.Also, it removes f2fs_truncate_data_blocks() for cleanup due to thefunction has only one caller, and uses f2fs_truncate_data_blocks_range()instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: annotate accesses to nlk->cb_runningBoth netlink_recvmsg() and netlink_native_seq_show() readnlk->cb_running locklessly. Use READ_ONCE() there.Add corresponding WRITE_ONCE() to netlink_dump() and__netlink_dump_start()syzbot reported:BUG: KCSAN: data-race in __netlink_dump_start / netlink_recvmsgwrite to 0xffff88813ea4db59 of 1 bytes by task 28219 on cpu 0:__netlink_dump_start+0x3af/0x4d0 net/netlink/af_netlink.c:2399netlink_dump_start include/linux/netlink.h:308 [inline]rtnetlink_rcv_msg+0x70f/0x8c0 net/core/rtnetlink.c:6130netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2577rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6192netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0x56f/0x640 net/netlink/af_netlink.c:1365netlink_sendmsg+0x665/0x770 net/netlink/af_netlink.c:1942sock_sendmsg_nosec net/socket.c:724 [inline]sock_sendmsg net/socket.c:747 [inline]sock_write_iter+0x1aa/0x230 net/socket.c:1138call_write_iter include/linux/fs.h:1851 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x463/0x760 fs/read_write.c:584ksys_write+0xeb/0x1a0 fs/read_write.c:637__do_sys_write fs/read_write.c:649 [inline]__se_sys_write fs/read_write.c:646 [inline]__x64_sys_write+0x42/0x50 fs/read_write.c:646do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread to 0xffff88813ea4db59 of 1 bytes by task 28222 on cpu 1:netlink_recvmsg+0x3b4/0x730 net/netlink/af_netlink.c:2022sock_recvmsg_nosec+0x4c/0x80 net/socket.c:1017____sys_recvmsg+0x2db/0x310 net/socket.c:2718___sys_recvmsg net/socket.c:2762 [inline]do_recvmmsg+0x2e5/0x710 net/socket.c:2856__sys_recvmmsg net/socket.c:2935 [inline]__do_sys_recvmmsg net/socket.c:2958 [inline]__se_sys_recvmmsg net/socket.c:2951 [inline]__x64_sys_recvmmsg+0xe2/0x160 net/socket.c:2951do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x00 -> 0x01

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: ocelot: call dsa_tag_8021q_unregister() under rtnl_lock() on driver removeWhen the tagging protocol in current use is "ocelot-8021q" and we unbindthe driver, we see this splat:$ echo '0000:00:00.2' > /sys/bus/pci/drivers/fsl_enetc/unbindmscc_felix 0000:00:00.5 swp0: left promiscuous modesja1105 spi2.0: Link is DownDSA: tree 1 torn downmscc_felix 0000:00:00.5 swp2: left promiscuous modesja1105 spi2.2: Link is DownDSA: tree 3 torn downfsl_enetc 0000:00:00.2 eno2: left promiscuous modemscc_felix 0000:00:00.5: Link is Down------------[ cut here ]------------RTNL: assertion failed at net/dsa/tag_8021q.c (409)WARNING: CPU: 1 PID: 329 at net/dsa/tag_8021q.c:409 dsa_tag_8021q_unregister+0x12c/0x1a0Modules linked in:CPU: 1 PID: 329 Comm: bash Not tainted 6.5.0-rc3+ #771pc : dsa_tag_8021q_unregister+0x12c/0x1a0lr : dsa_tag_8021q_unregister+0x12c/0x1a0Call trace: dsa_tag_8021q_unregister+0x12c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50---[ end trace 0000000000000000 ]---------------[ cut here ]------------RTNL: assertion failed at net/8021q/vlan_core.c (376)WARNING: CPU: 1 PID: 329 at net/8021q/vlan_core.c:376 vlan_vid_del+0x1b8/0x1f0CPU: 1 PID: 329 Comm: bash Tainted: G W 6.5.0-rc3+ #771pc : vlan_vid_del+0x1b8/0x1f0lr : vlan_vid_del+0x1b8/0x1f0 dsa_tag_8021q_unregister+0x8c/0x1a0 felix_tag_8021q_teardown+0x130/0x150 felix_teardown+0x3c/0xd8 dsa_tree_teardown_switches+0xbc/0xe0 dsa_unregister_switch+0x168/0x260 felix_pci_remove+0x30/0x60 pci_device_remove+0x4c/0x100 device_release_driver_internal+0x188/0x288 device_links_unbind_consumers+0xfc/0x138 device_release_driver_internal+0xe0/0x288 device_driver_detach+0x24/0x38 unbind_store+0xd8/0x108 drv_attr_store+0x30/0x50DSA: tree 0 torn downThis was somewhat not so easy to spot, because "ocelot-8021q" is not thedefault tagging protocol, and thus, not everyone who tests the unbindingpath may have switched to it beforehand. The defaultfelix_tag_npi_teardown() does not require rtnl_lock() to be held.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: overlay: Call of_changeset_init() earlyWhen of_overlay_fdt_apply() fails, the changeset may be partiallyapplied, and the caller is still expected to call of_overlay_remove() toclean up this partial state.However, of_overlay_apply() calls of_resolve_phandles() beforeinit_overlay_changeset(). Hence if the overlay fails to apply due to anunresolved symbol, the overlay_changeset.cset.entries list is stilluninitialized, and cleanup will crash with a NULL-pointer dereference inoverlay_removal_is_ok().Fix this by moving the call to of_changeset_init() frominit_overlay_changeset() to of_overlay_fdt_apply(), where all otherearly initialization is done.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: do not hard code device address lenth in fdb dumpssyzbot reports that some netdev devices do not have a six bytesaddress [1]Replace ETH_ALEN by dev->addr_len.[1] (Case of a device where dev->addr_len = 4)BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copyout+0xb8/0x100 lib/iov_iter.c:169instrument_copy_to_user include/linux/instrumented.h:114 [inline]copyout+0xb8/0x100 lib/iov_iter.c:169_copy_to_iter+0x6d8/0x1d00 lib/iov_iter.c:536copy_to_iter include/linux/uio.h:206 [inline]simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:513__skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:527skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]netlink_recvmsg+0x4ae/0x15a0 net/netlink/af_netlink.c:1970sock_recvmsg_nosec net/socket.c:1019 [inline]sock_recvmsg net/socket.c:1040 [inline]____sys_recvmsg+0x283/0x7f0 net/socket.c:2722___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was stored to memory at:__nla_put lib/nlattr.c:1009 [inline]nla_put+0x1c6/0x230 lib/nlattr.c:1067nlmsg_populate_fdb_fill+0x2b8/0x600 net/core/rtnetlink.c:4071nlmsg_populate_fdb net/core/rtnetlink.c:4418 [inline]ndo_dflt_fdb_dump+0x616/0x840 net/core/rtnetlink.c:4456rtnl_fdb_dump+0x14ff/0x1fc0 net/core/rtnetlink.c:4629netlink_dump+0x9d1/0x1310 net/netlink/af_netlink.c:2268netlink_recvmsg+0xc5c/0x15a0 net/netlink/af_netlink.c:1995sock_recvmsg_nosec+0x7a/0x120 net/socket.c:1019____sys_recvmsg+0x664/0x7f0 net/socket.c:2720___sys_recvmsg+0x223/0x840 net/socket.c:2764do_recvmmsg+0x4f9/0xfd0 net/socket.c:2858__sys_recvmmsg net/socket.c:2937 [inline]__do_sys_recvmmsg net/socket.c:2960 [inline]__se_sys_recvmmsg net/socket.c:2953 [inline]__x64_sys_recvmmsg+0x397/0x490 net/socket.c:2953do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdUninit was created at:slab_post_alloc_hook+0x12d/0xb60 mm/slab.h:716slab_alloc_node mm/slub.c:3451 [inline]__kmem_cache_alloc_node+0x4ff/0x8b0 mm/slub.c:3490kmalloc_trace+0x51/0x200 mm/slab_common.c:1057kmalloc include/linux/slab.h:559 [inline]__hw_addr_create net/core/dev_addr_lists.c:60 [inline]__hw_addr_add_ex+0x2e5/0x9e0 net/core/dev_addr_lists.c:118__dev_mc_add net/core/dev_addr_lists.c:867 [inline]dev_mc_add+0x9a/0x130 net/core/dev_addr_lists.c:885igmp6_group_added+0x267/0xbc0 net/ipv6/mcast.c:680ipv6_mc_up+0x296/0x3b0 net/ipv6/mcast.c:2754ipv6_mc_remap+0x1e/0x30 net/ipv6/mcast.c:2708addrconf_type_change net/ipv6/addrconf.c:3731 [inline]addrconf_notify+0x4d3/0x1d90 net/ipv6/addrconf.c:3699notifier_call_chain kernel/notifier.c:93 [inline]raw_notifier_call_chain+0xe4/0x430 kernel/notifier.c:461call_netdevice_notifiers_info net/core/dev.c:1935 [inline]call_netdevice_notifiers_extack net/core/dev.c:1973 [inline]call_netdevice_notifiers+0x1ee/0x2d0 net/core/dev.c:1987bond_enslave+0xccd/0x53f0 drivers/net/bonding/bond_main.c:1906do_set_master net/core/rtnetlink.c:2626 [inline]rtnl_newlink_create net/core/rtnetlink.c:3460 [inline]__rtnl_newlink net/core/rtnetlink.c:3660 [inline]rtnl_newlink+0x378c/0x40e0 net/core/rtnetlink.c:3673rtnetlink_rcv_msg+0x16a6/0x1840 net/core/rtnetlink.c:6395netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2546rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6413netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]netlink_unicast+0xf28/0x1230 net/netlink/af_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix warning when putting transaction with qgroups enabled after abortIf we have a transaction abort with qgroups enabled we get a warningtriggered when doing the final put on the transaction, like this: [552.6789] ------------[ cut here ]------------ [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs] [552.6817] Modules linked in: btrfs blake2b_generic xor (...) [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014 [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs] [552.6821] Code: bd a0 01 00 (...) [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286 [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000 [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010 [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20 [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70 [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028 [552.6821] FS: 0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000 [552.6821] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0 [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [552.6822] Call Trace: [552.6822] [552.6822] ? __warn+0x80/0x130 [552.6822] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6824] ? report_bug+0x1f4/0x200 [552.6824] ? handle_bug+0x42/0x70 [552.6824] ? exc_invalid_op+0x14/0x70 [552.6824] ? asm_exc_invalid_op+0x16/0x20 [552.6824] ? btrfs_put_transaction+0x123/0x130 [btrfs] [552.6826] btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs] [552.6828] ? _raw_spin_unlock_irqrestore+0x23/0x40 [552.6828] ? try_to_wake_up+0x94/0x5e0 [552.6828] ? __pfx_process_timeout+0x10/0x10 [552.6828] transaction_kthread+0x103/0x1d0 [btrfs] [552.6830] ? __pfx_transaction_kthread+0x10/0x10 [btrfs] [552.6832] kthread+0xee/0x120 [552.6832] ? __pfx_kthread+0x10/0x10 [552.6832] ret_from_fork+0x29/0x50 [552.6832] [552.6832] ---[ end trace 0000000000000000 ]---This corresponds to this line of code: void btrfs_put_transaction(struct btrfs_transaction *transaction) { (...) WARN_ON(!RB_EMPTY_ROOT( &transaction->delayed_refs.dirty_extent_root)); (...) }The warning happens because btrfs_qgroup_destroy_extent_records(), calledin the transaction abort path, we free all entries from the rbtree"dirty_extent_root" with rbtree_postorder_for_each_entry_safe(), but wedon't actually empty the rbtree - it's still pointing to nodes that werefreed.So set the rbtree's root node to NULL to avoid this warning (assignRB_ROOT).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix potential use-after-free bug when trimming capsWhen trimming the caps and just after the 'session->s_cap_lock' isreleased in ceph_iterate_session_caps() the cap maybe removed byanother thread, and when using the stale cap memory in the callbacksit will trigger use-after-free crash.We need to check the existence of the cap just after the 'ci->i_ceph_lock'being acquired. And do nothing if it's already removed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mips: bmips: BCM6358: disable RAC flush for TP1RAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:[ 3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform[ 3.895011] Reserved instruction in kernel code[#1]:[ 3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0[ 3.905829] $ 0 : 00000000 10008700 00000000 77d94060[ 3.911238] $ 4 : 7fd1f088 00000000 81431cac 81431ca0[ 3.916641] $ 8 : 00000000 ffffefff 8075cd34 00000000[ 3.922043] $12 : 806f8d40 f3e812b7 00000000 000d9aaa[ 3.927446] $16 : 7fd1f068 7fd1f080 7ff559b8 81428470[ 3.932848] $20 : 00000000 00000000 55590000 77d70000[ 3.938251] $24 : 00000018 00000010[ 3.943655] $28 : 81430000 81431e60 81431f28 800157fc[ 3.949058] Hi : 00000000[ 3.952013] Lo : 00000000[ 3.955019] epc : 80015808 setup_sigcontext+0x54/0x24c[ 3.960464] ra : 800157fc setup_sigcontext+0x48/0x24c[ 3.965913] Status: 10008703 KERNEL EXL IE[ 3.970216] Cause : 00800028 (ExcCode 0a)[ 3.974340] PrId : 0002a010 (Broadcom BMIPS4350)[ 3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common[ 3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)[ 4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470[ 4.009467] 81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74[ 4.018149] 08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003[ 4.026831] ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000[ 4.035512] 77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000[ 4.044196] ...[ 4.046706] Call Trace:[ 4.049238] [<80015808>] setup_sigcontext+0x54/0x24c[ 4.054356] [<80015c70>] setup_frame+0xdc/0x124[ 4.059015] [<80016414>] do_notify_resume+0x1dc/0x288[ 4.064207] [<80011b50>] work_notifysig+0x10/0x18[ 4.069036][ 4.070538] Code: 8fc300b4 00001025 26240008 ac830004 3c048063 0c0228aa 24846a00 26240010[ 4.080686][ 4.082517] ---[ end trace 22a8edb41f5f983b ]---[ 4.087374] Kernel panic - not syncing: Fatal exception[ 4.092753] Rebooting in 1 seconds..Because the bootloader (CFE) is not initializing the Read-ahead cache properlyon the second thread (TP1). Since the RAC was not initialized properly, weshould avoid flushing it at the risk of corrupting the instruction stream asseen in the trace above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: mm: fix VA-range sanity checkBoth create_mapping_noalloc() and update_mapping_prot() sanity-checktheir 'virt' parameter, but the check itself doesn't make much sense.The condition used today appears to be a historical accident.The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }... can only be true for the KASAN shadow region or the module region,and there's no reason to exclude these specifically for creating andupdateing mappings.When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation")... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; }At the time, VMALLOC_START was the lowest kernel address, and this waschecking whether 'virt' would be translated via TTBR1.Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space")... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }This appear to have been a thinko. The commit moved the linear map tothe bottom of the kernel address space, with VMALLOC_START being at thehalfway point. The old condition would warn for changes to the linearmap below this, and at the time VA_START was the end of the linear map.Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename VA_START to PAGE_END")... keeping the erroneous condition as: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }Correct the condition to check against the start of the TTBR1 addressspace, which is currently PAGE_OFFSET. This simplifies the logic, andmore clearly matches the "outside kernel range" message in the warning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: ocb: don't leave if not joinedIf there's no OCB state, don't ask the driver/mac80211 toleave, since that's just confusing. Since set/clear thechandef state, that's a simple check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: remove WARN_ON to prevent panic_on_warnRemove unnecessary early code development check and the WARN_ONthat it uses. The irq alloc and free paths have long beencleaned up and this check shouldn't have stuck around so long.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54004 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udplite: Fix NULL pointer dereference in __sk_mem_raise_allocated().syzbot reported [0] a null-ptr-deref in sk_get_rmem0() while usingIPPROTO_UDPLITE (0x88): 14:25:52 executing program 1: r0 = socket$inet6(0xa, 0x80002, 0x88)We had a similar report [1] for probably sk_memory_allocated_add()in __sk_mem_raise_allocated(), and commit c915fe13cbaa ("udplite: fixNULL pointer dereference") fixed it by setting .memory_allocated forudplite_prot and udplitev6_prot.To fix the variant, we need to set either .sysctl_wmem_offset or.sysctl_rmem.Now UDP and UDPLITE share the same value for .memory_allocated, so weuse the same .sysctl_wmem_offset for UDP and UDPLITE.[0]:general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 6829 Comm: syz-executor.1 Not tainted 6.4.0-rc2-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023RIP: 0010:sk_get_rmem0 include/net/sock.h:2907 [inline]RIP: 0010:__sk_mem_raise_allocated+0x806/0x17a0 net/core/sock.c:3006Code: c1 ea 03 80 3c 02 00 0f 85 23 0f 00 00 48 8b 44 24 08 48 8b 98 38 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <0f> b6 14 02 48 89 d8 83 e0 07 83 c0 03 38 d0 0f 8d 6f 0a 00 00 8bRSP: 0018:ffffc90005d7f450 EFLAGS: 00010246RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004d92000RDX: 0000000000000000 RSI: ffffffff88066482 RDI: ffffffff8e2ccbb8RBP: ffff8880173f7000 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000030000R13: 0000000000000001 R14: 0000000000000340 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9800000(0063) knlGS:00000000f7f1cb40CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033CR2: 000000002e82f000 CR3: 0000000034ff0000 CR4: 00000000003506f0Call Trace: __sk_mem_schedule+0x6c/0xe0 net/core/sock.c:3077 udp_rmem_schedule net/ipv4/udp.c:1539 [inline] __udp_enqueue_schedule_skb+0x776/0xb30 net/ipv4/udp.c:1581 __udpv6_queue_rcv_skb net/ipv6/udp.c:666 [inline] udpv6_queue_rcv_one_skb+0xc39/0x16c0 net/ipv6/udp.c:775 udpv6_queue_rcv_skb+0x194/0xa10 net/ipv6/udp.c:793 __udp6_lib_mcast_deliver net/ipv6/udp.c:906 [inline] __udp6_lib_rcv+0x1bda/0x2bd0 net/ipv6/udp.c:1013 ip6_protocol_deliver_rcu+0x2e7/0x1250 net/ipv6/ip6_input.c:437 ip6_input_finish+0x150/0x2f0 net/ipv6/ip6_input.c:482 NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ip6_input+0xa0/0xd0 net/ipv6/ip6_input.c:491 ip6_mc_input+0x40b/0xf50 net/ipv6/ip6_input.c:585 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish net/ipv6/ip6_input.c:79 [inline] NF_HOOK include/linux/netfilter.h:303 [inline] NF_HOOK include/linux/netfilter.h:297 [inline] ipv6_rcv+0x250/0x380 net/ipv6/ip6_input.c:309 __netif_receive_skb_one_core+0x114/0x180 net/core/dev.c:5491 __netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5605 netif_receive_skb_internal net/core/dev.c:5691 [inline] netif_receive_skb+0x133/0x7a0 net/core/dev.c:5750 tun_rx_batched+0x4b3/0x7a0 drivers/net/tun.c:1553 tun_get_user+0x2452/0x39c0 drivers/net/tun.c:1989 tun_chr_write_iter+0xdf/0x200 drivers/net/tun.c:2035 call_write_iter include/linux/fs.h:1868 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x945/0xd50 fs/read_write.c:584 ksys_write+0x12b/0x250 fs/read_write.c:637 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0x65/0xf0 arch/x86/entry/common.c:178 do_fast_syscall_32+0x33/0x70 arch/x86/entry/common.c:203 entry_SYSENTER_compat_after_hwframe+0x70/0x82RIP: 0023:0xf7f21579Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:binder: fix memory leak in binder_init()In binder_init(), the destruction of binder_alloc_shrinker_init() is notperformed in the wrong path, which will cause memory leaks. So this commitintroduces binder_alloc_shrinker_exit() and calls it in the wrong path tofix that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54012 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix stack overflow when LRO is disabled for virtual interfacesWhen the virtual interface's feature is updated, it synchronizes theupdated feature for its own lower interface.This propagation logic should be worked as the iteration, not recursively.But it works recursively due to the netdev notification unexpectedly.This problem occurs when it disables LRO only for the team and bondinginterface type. team0 | +------+------+-----+-----+ | | | | |team1 team2 team3 ... team200If team0's LRO feature is updated, it generates the NETDEV_FEAT_CHANGEevent to its own lower interfaces(team1 ~ team200).It is worked by netdev_sync_lower_features().So, the NETDEV_FEAT_CHANGE notification logic of each lower interfacework iteratively.But generated NETDEV_FEAT_CHANGE event is also sent to the upperinterface too.upper interface(team0) generates the NETDEV_FEAT_CHANGE event for its ownlower interfaces again.lower and upper interfaces receive this event and generate thisevent again and again.So, the stack overflow occurs.But it is not the infinite loop issue.Because the netdev_sync_lower_features() updates features beforegenerating the NETDEV_FEAT_CHANGE event.Already synchronized lower interfaces skip notification logic.So, it is just the problem that iteration logic is changed to therecursive unexpectedly due to the notification mechanism.Reproducer:ip link add team0 type teamethtool -K team0 lro onfor i in {1..200}do ip link add team$i master team0 type team ethtool -K team$i lro ondoneethtool -K team0 lro offIn order to fix it, the notifier_ctx member of bonding/team is introduced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54023 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between balance and cancel/pauseSyzbot reported a panic that looks like this: assertion failed: fs_info->exclusive_operation == BTRFS_EXCLOP_BALANCE_PAUSED, in fs/btrfs/ioctl.c:465 ------------[ cut here ]------------ kernel BUG at fs/btrfs/messages.c:259! RIP: 0010:btrfs_assertfail+0x2c/0x30 fs/btrfs/messages.c:259 Call Trace: btrfs_exclop_balance fs/btrfs/ioctl.c:465 [inline] btrfs_ioctl_balance fs/btrfs/ioctl.c:3564 [inline] btrfs_ioctl+0x531e/0x5b30 fs/btrfs/ioctl.c:4632 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe reproducer is running a balance and a cancel or pause in parallel.The way balance finishes is a bit wonky, if we were paused we need tosave the balance_ctl in the fs_info, but clear it otherwise and cleanup.However we rely on the return values being specific errors, or having acancel request or no pause request. If balance completes and returns 0,but we have a pause or cancel request we won't do the appropriatecleanup, and then the next time we try to start a balance we'll tripthis ASSERT.The error handling is just wrong here, we always want to clean up,unless we got -ECANCELLED and we set the appropriate pause flag in theexclusive op. With this patch the reproducer ran for an hour withouttripping, previously it would trip in less than a few minutes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54032 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting quota root from the dirty cow roots listWhen disabling quotas we are deleting the quota root from the listfs_info->dirty_cowonly_roots without taking the lock that protects it,which is struct btrfs_fs_info::trans_lock. This unsynchronized listmanipulation may cause chaos if there's another concurrent manipulationof this list, such as when adding a root to it withctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe quota root from that list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix a memory leak in the LRU and LRU_PERCPU hash mapsThe LRU and LRU_PERCPU maps allocate a new element on update before locking thetarget hash table bucket. Right after that the maps try to lock the bucket.If this fails, then maps return -EBUSY to the caller without releasing theallocated element. This makes the element untracked: it doesn't belong toeither of free lists, and it doesn't belong to the hash table, so can't bere-used; this eventually leads to the permanent -ENOMEM on LRU map updates,which is unexpected. Fix this by returning the element to the local free listif bucket locking fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54047 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: dw_hdmi: cleanup drm encoder during unbindThis fixes a use-after-free crash during rmmod.The DRM encoder is embedded inside the larger rockchip_hdmi,which is allocated with the component. The component memorygets freed before the main drm device is destroyed. Fix itby running encoder cleanup before tearing down its container.[moved encoder cleanup above clk_disable, similar to bind-error-path]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: mt7921: fix skb leak by txs missing in AMSDUtxs may be dropped if the frame is aggregated in AMSDU. When the problemshows up, some SKBs would be hold in driver to cause network stoppedtemporarily. Even if the problem can be recovered by txs timeout handling,mt7921 still need to disable txs in AMSDU to avoid this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kheaders: Use array declaration instead of charUnder CONFIG_FORTIFY_SOURCE, memcpy() will check the size of destinationand source buffers. Defining kernel_headers_data as "char" would tripthis check. Since these addresses are treated as byte arrays, definethem as arrays (as done everywhere else).This was seen with: $ cat /sys/kernel/kheaders.tar.xz >> /dev/null detected buffer overflow in memcpy kernel BUG at lib/string_helpers.c:1027! ... RIP: 0010:fortify_panic+0xf/0x20 [...] Call Trace: ikheaders_read+0x45/0x50 [kheaders] kernfs_fop_read_iter+0x1a4/0x2f0 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Add a length limitation for the ivrs_acpihid command-line parameterThe 'acpiid' buffer in the parse_ivrs_acpihid function may overflow,because the string specifier in the format string sscanf()has no width limitation.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: gl861: Fix null-ptr-deref in gl861_i2c_master_xferIn gl861_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach gl861_i2c_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race when deleting free space root from the dirty cow roots listWhen deleting the free space tree we are deleting the free space rootfrom the list fs_info->dirty_cowonly_roots without taking the lock thatprotects it, which is struct btrfs_fs_info::trans_lock.This unsynchronized list manipulation may cause chaos if there's anotherconcurrent manipulation of this list, such as when adding a root to itwith ctree.c:add_root_to_dirty_list().This can result in all sorts of weird failures caused by a race, such asthe following crash: [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G W 6.4.0-rc6-btrfs-next-134+ #1 [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.279928] Code: 85 38 06 00 (...) [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206 [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000 [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070 [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600 [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48 [337571.281723] FS: 00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000 [337571.281950] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0 [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [337571.282874] Call Trace: [337571.283101] [337571.283327] ? __die_body+0x1b/0x60 [337571.283570] ? die_addr+0x39/0x60 [337571.283796] ? exc_general_protection+0x22e/0x430 [337571.284022] ? asm_exc_general_protection+0x22/0x30 [337571.284251] ? commit_cowonly_roots+0x11f/0x250 [btrfs] [337571.284531] btrfs_commit_transaction+0x42e/0xf90 [btrfs] [337571.284803] ? _raw_spin_unlock+0x15/0x30 [337571.285031] ? release_extent_buffer+0x103/0x130 [btrfs] [337571.285305] reset_balance_state+0x152/0x1b0 [btrfs] [337571.285578] btrfs_balance+0xa50/0x11e0 [btrfs] [337571.285864] ? __kmem_cache_alloc_node+0x14a/0x410 [337571.286086] btrfs_ioctl+0x249a/0x3320 [btrfs] [337571.286358] ? mod_objcg_state+0xd2/0x360 [337571.286577] ? refill_obj_stock+0xb0/0x160 [337571.286798] ? seq_release+0x25/0x30 [337571.287016] ? __rseq_handle_notify_resume+0x3ba/0x4b0 [337571.287235] ? percpu_counter_add_batch+0x2e/0xa0 [337571.287455] ? __x64_sys_ioctl+0x88/0xc0 [337571.287675] __x64_sys_ioctl+0x88/0xc0 [337571.287901] do_syscall_64+0x38/0x90 [337571.288126] entry_SYSCALL_64_after_hwframe+0x72/0xdc [337571.288352] RIP: 0033:0x7f478aaffe9bSo fix this by locking struct btrfs_fs_info::trans_lock before deletingthe free space root from that list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54070 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: clean up in all error paths when enabling SR-IOVAfter commit 50f303496d92 ("igb: Enable SR-IOV after reinit"), removingthe igb module could hang or crash (depending on the machine) when themodule has been loaded with the max_vfs parameter set to some value != 0.In case of one test machine with a dual port 82580, this hang occurred:[ 232.480687] igb 0000:41:00.1: removed PHC on enp65s0f1[ 233.093257] igb 0000:41:00.1: IOV Disabled[ 233.329969] pcieport 0000:40:01.0: AER: Multiple Uncorrected (Non-Fatal) err0[ 233.340302] igb 0000:41:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.352248] igb 0000:41:00.0: device [8086:1516] error status/mask=00100000[ 233.361088] igb 0000:41:00.0: [20] UnsupReq (First)[ 233.368183] igb 0000:41:00.0: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.376846] igb 0000:41:00.1: PCIe Bus Error: severity=Uncorrected (Non-Fata)[ 233.388779] igb 0000:41:00.1: device [8086:1516] error status/mask=00100000[ 233.397629] igb 0000:41:00.1: [20] UnsupReq (First)[ 233.404736] igb 0000:41:00.1: AER: TLP Header: 40000001 0000040f cdbfc00c c[ 233.538214] pci 0000:41:00.1: AER: can't recover (no error_detected callback)[ 233.538401] igb 0000:41:00.0: removed PHC on enp65s0f0[ 233.546197] pcieport 0000:40:01.0: AER: device recovery failed[ 234.157244] igb 0000:41:00.0: IOV Disabled[ 371.619705] INFO: task irq/35-aerdrv:257 blocked for more than 122 seconds.[ 371.627489] Not tainted 6.4.0-dirty #2[ 371.632257] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this.[ 371.641000] task:irq/35-aerdrv state:D stack:0 pid:257 ppid:2 f0[ 371.650330] Call Trace:[ 371.653061] [ 371.655407] __schedule+0x20e/0x660[ 371.659313] schedule+0x5a/0xd0[ 371.662824] schedule_preempt_disabled+0x11/0x20[ 371.667983] __mutex_lock.constprop.0+0x372/0x6c0[ 371.673237] ? __pfx_aer_root_reset+0x10/0x10[ 371.678105] report_error_detected+0x25/0x1c0[ 371.682974] ? __pfx_report_normal_detected+0x10/0x10[ 371.688618] pci_walk_bus+0x72/0x90[ 371.692519] pcie_do_recovery+0xb2/0x330[ 371.696899] aer_process_err_devices+0x117/0x170[ 371.702055] aer_isr+0x1c0/0x1e0[ 371.705661] ? __set_cpus_allowed_ptr+0x54/0xa0[ 371.710723] ? __pfx_irq_thread_fn+0x10/0x10[ 371.715496] irq_thread_fn+0x20/0x60[ 371.719491] irq_thread+0xe6/0x1b0[ 371.723291] ? __pfx_irq_thread_dtor+0x10/0x10[ 371.728255] ? __pfx_irq_thread+0x10/0x10[ 371.732731] kthread+0xe2/0x110[ 371.736243] ? __pfx_kthread+0x10/0x10[ 371.740430] ret_from_fork+0x2c/0x50[ 371.744428] The reproducer was a simple script: #!/bin/sh for i in `seq 1 5`; do modprobe -rv igb modprobe -v igb max_vfs=1 sleep 1 modprobe -rv igb doneIt turned out that this could only be reproduce on 82580 (quad anddual-port), but not on 82576, i350 and i210. Further debugging showedthat igb_enable_sriov()'s call to pci_enable_sriov() is failing, becausedev->is_physfn is 0 on 82580.Prior to commit 50f303496d92 ("igb: Enable SR-IOV after reinit"),igb_enable_sriov() jumped into the "err_out" cleanup branch. After thiscommit it only returned the error code.So the cleanup didn't take place, and the incorrect VF setup in theigb_adapter structure fooled the igb driver into assuming that VFs havebeen set up where no VF actually existed.Fix this problem by cleaning up again if pci_enable_sriov() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen: speed up grant-table reclaimWhen a grant entry is still in use by the remote domain, Linux must putit on a deferred list. Normally, this list is very short, becausethe PV network and block protocols expect the backend to unmap the grantfirst. However, Qubes OS's GUI protocol is subject to the constraintsof the X Window System, and as such winds up with the frontend unmappingthe window first. As a result, the list can grow very large, resultingin a massive memory leak and eventual VM freeze.To partially solve this problem, make the number of entries that the VMwill attempt to free at each iteration tunable. The default is still10, but it can be overridden via a module parameter.This is Cc: stable because (when combined with appropriate userspacechanges) it fixes a severe performance and stability problem for QubesOS users.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Add preempt_count_{sub,add} into btf id deny listThe recursion check in __bpf_prog_enter* and __bpf_prog_exit*leave preempt_count_{sub,add} unprotected. When attaching trampoline tothem we get panic as follows,[ 867.843050] BUG: TASK stack guard page was hit at 0000000009d325cf (stack is 0000000046a46a15..00000000537e7b28)[ 867.843064] stack guard page: 0000 [#1] PREEMPT SMP NOPTI[ 867.843067] CPU: 8 PID: 11009 Comm: trace Kdump: loaded Not tainted 6.2.0+ #4[ 867.843100] Call Trace:[ 867.843101] [ 867.843104] asm_exc_int3+0x3a/0x40[ 867.843108] RIP: 0010:preempt_count_sub+0x1/0xa0[ 867.843135] __bpf_prog_enter_recur+0x17/0x90[ 867.843148] bpf_trampoline_6442468108_0+0x2e/0x1000[ 867.843154] ? preempt_count_sub+0x1/0xa0[ 867.843157] preempt_count_sub+0x5/0xa0[ 867.843159] ? migrate_enable+0xac/0xf0[ 867.843164] __bpf_prog_exit_recur+0x2d/0x40[ 867.843168] bpf_trampoline_6442468108_0+0x55/0x1000...[ 867.843788] preempt_count_sub+0x5/0xa0[ 867.843793] ? migrate_enable+0xac/0xf0[ 867.843829] __bpf_prog_exit_recur+0x2d/0x40[ 867.843837] BUG: IRQ stack guard page was hit at 0000000099bd8228 (stack is 00000000b23e2bc4..000000006d95af35)[ 867.843841] BUG: IRQ stack guard page was hit at 000000005ae07924 (stack is 00000000ffd69623..0000000014eb594c)[ 867.843843] BUG: IRQ stack guard page was hit at 00000000028320f0 (stack is 00000000034b6438..0000000078d1bcec)[ 867.843842] bpf_trampoline_6442468108_0+0x55/0x1000...That is because in __bpf_prog_exit_recur, the preempt_count_{sub,add} arecalled after prog->active is decreased.Fixing this by adding these two functions into btf ids deny list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix possible null-ptr-deref in ubi_free_volume()It willl cause null-ptr-deref in the following case:uif_init() ubi_add_volume() cdev_add() -> if it fails, call kill_volumes() device_register()kill_volumes() -> if ubi_add_volume() fails call this function ubi_free_volume() cdev_del() device_unregister() -> trying to delete a not added device, it causes null-ptr-derefSo in ubi_free_volume(), it delete devices whether they are addedor not, it will causes null-ptr-deref.Handle the error case whlie calling ubi_add_volume() to fix thisproblem. If add volume fails, set the corresponding vol to null,so it can not be accessed in kill_volumes() and release theresource in ubi_add_volume() error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: anysee: fix null-ptr-deref in anysee_master_xferIn anysee_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach anysee_master_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")[hverkuil: add spaces around +]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent skb corruption on frag list segmentationIan reported several skb corruptions triggered by rx-gro-list,collecting different oops alike:[ 62.624003] BUG: kernel NULL pointer dereference, address: 00000000000000c0[ 62.631083] #PF: supervisor read access in kernel mode[ 62.636312] #PF: error_code(0x0000) - not-present page[ 62.641541] PGD 0 P4D 0[ 62.644174] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 62.648629] CPU: 1 PID: 913 Comm: napi/eno2-79 Not tainted 6.4.0 #364[ 62.655162] Hardware name: Supermicro Super Server/A2SDi-12C-HLN4F, BIOS 1.7a 10/13/2022[ 62.663344] RIP: 0010:__udp_gso_segment (./include/linux/skbuff.h:2858./include/linux/udp.h:23 net/ipv4/udp_offload.c:228 net/ipv4/udp_offload.c:261net/ipv4/udp_offload.c:277)[ 62.687193] RSP: 0018:ffffbd3a83b4f868 EFLAGS: 00010246[ 62.692515] RAX: 00000000000000ce RBX: 0000000000000000 RCX: 0000000000000000[ 62.699743] RDX: ffffa124def8a000 RSI: 0000000000000079 RDI: ffffa125952a14d4[ 62.706970] RBP: ffffa124def8a000 R08: 0000000000000022 R09: 00002000001558c9[ 62.714199] R10: 0000000000000000 R11: 00000000be554639 R12: 00000000000000e2[ 62.721426] R13: ffffa125952a1400 R14: ffffa125952a1400 R15: 00002000001558c9[ 62.728654] FS: 0000000000000000(0000) GS:ffffa127efa40000(0000)knlGS:0000000000000000[ 62.736852] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 62.742702] CR2: 00000000000000c0 CR3: 00000001034b0000 CR4: 00000000003526e0[ 62.749948] Call Trace:[ 62.752498] [ 62.779267] inet_gso_segment (net/ipv4/af_inet.c:1398)[ 62.787605] skb_mac_gso_segment (net/core/gro.c:141)[ 62.791906] __skb_gso_segment (net/core/dev.c:3403 (discriminator 2))[ 62.800492] validate_xmit_skb (./include/linux/netdevice.h:4862net/core/dev.c:3659)[ 62.804695] validate_xmit_skb_list (net/core/dev.c:3710)[ 62.809158] sch_direct_xmit (net/sched/sch_generic.c:330)[ 62.813198] __dev_queue_xmit (net/core/dev.c:3805 net/core/dev.c:4210)net/netfilter/core.c:626)[ 62.821093] br_dev_queue_push_xmit (net/bridge/br_forward.c:55)[ 62.825652] maybe_deliver (net/bridge/br_forward.c:193)[ 62.829420] br_flood (net/bridge/br_forward.c:233)[ 62.832758] br_handle_frame_finish (net/bridge/br_input.c:215)[ 62.837403] br_handle_frame (net/bridge/br_input.c:298net/bridge/br_input.c:416)[ 62.851417] __netif_receive_skb_core.constprop.0 (net/core/dev.c:5387)[ 62.866114] __netif_receive_skb_list_core (net/core/dev.c:5570)[ 62.871367] netif_receive_skb_list_internal (net/core/dev.c:5638net/core/dev.c:5727)[ 62.876795] napi_complete_done (./include/linux/list.h:37./include/net/gro.h:434 ./include/net/gro.h:429 net/core/dev.c:6067)[ 62.881004] ixgbe_poll (drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:3191)[ 62.893534] __napi_poll (net/core/dev.c:6498)[ 62.897133] napi_threaded_poll (./include/linux/netpoll.h:89net/core/dev.c:6640)[ 62.905276] kthread (kernel/kthread.c:379)[ 62.913435] ret_from_fork (arch/x86/entry/entry_64.S:314)[ 62.917119] In the critical scenario, rx-gro-list GRO-ed packets are fed, via abridge, both to the local input path and to an egress device (tun).The segmentation of such packets unsafely writes to the cloned skbswith shared heads.This change addresses the issue by uncloning as needed theto-be-segmented skbs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: Protect reconfiguration of sb read-write from racing writesThe reconfigure / remount code takes a lot of effort to protectfilesystem's reconfiguration code from racing writes on remountingread-only. However during remounting read-only filesystem to read-writemode userspace writes can start immediately once we clear SB_RDONLYflag. This is inconvenient for example for ext4 because we need to dosome writes to the filesystem (such as preparation of quota files)before we can take userspace writes so we are clearing SB_RDONLY flagbefore we are fully ready to accept userpace writes and syzbot has founda way to exploit this [1]. Also as far as I'm reading the codethe filesystem remount code was protected from racing writes in thelegacy mount path by the mount's MNT_READONLY flag so this is relativelynew problem. It is actually fairly easy to protect remount read-writefrom racing writes using sb->s_readonly_remount flag so let's just dothat instead of having to workaround these races in the filesystem code.[1] https://lore.kernel.org/all/00000000000006a0df05f6667499@google.com/T/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rcar_fdp1: Fix refcount leak in probe and remove functionrcar_fcp_get() take reference, which should be balanced withrcar_fcp_put(). Add missing rcar_fcp_put() in fdp1_remove andthe error paths of fdp1_probe() to fix this.[hverkuil: resolve merge conflict, remove() is now void]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: Fix memory leak in error path of kcm_sendmsg()syzbot reported a memory leak like below:BUG: memory leakunreferenced object 0xffff88810b088c00 (size 240): comm "syz-executor186", pid 5012, jiffies 4294943306 (age 13.680s) hex dump (first 32 bytes): 00 89 08 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [] __alloc_skb+0x1ef/0x230 net/core/skbuff.c:634 [] alloc_skb include/linux/skbuff.h:1289 [inline] [] kcm_sendmsg+0x269/0x1050 net/kcm/kcmsock.c:815 [] sock_sendmsg_nosec net/socket.c:725 [inline] [] sock_sendmsg+0x56/0xb0 net/socket.c:748 [] ____sys_sendmsg+0x365/0x470 net/socket.c:2494 [] ___sys_sendmsg+0xc9/0x130 net/socket.c:2548 [] __sys_sendmsg+0xa6/0x120 net/socket.c:2577 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdIn kcm_sendmsg(), kcm_tx_msg(head)->last_skb is used as a cursor to appendnewly allocated skbs to 'head'. If some bytes are copied, an error occurred,and jumped to out_error label, 'last_skb' is left unmodified. A laterkcm_sendmsg() will use an obsoleted 'last_skb' reference, corrupting the'head' frag_list and causing the leak.This patch fixes this issue by properly updating the last allocated skb in'last_skb'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: dump vmalloc memory info safelyCurrently, for double invoke call_rcu(), will dump rcu_head objects memoryinfo, if the objects is not allocated from the slab allocator, thevmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need tobe held, since the call_rcu() can be invoked in interrupt context,therefore, there is a possibility of spinlock deadlock scenarios.And in Preempt-RT kernel, the rcutorture test also trigger the followinglockdep warning:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0preempt_count: 1, expected: 0RCU nest depth: 1, expected: 13 locks held by swapper/0/1: #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0 #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370 #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70irq event stamp: 565512hardirqs last enabled at (565511): [] __call_rcu_common+0x218/0x940hardirqs last disabled at (565512): [] rcu_torture_init+0x20b2/0x2370softirqs last enabled at (399112): [] __local_bh_enable_ip+0x126/0x170softirqs last disabled at (399106): [] inet_register_protosw+0x9/0x1d0Preemption disabled at:[] rcu_torture_init+0x1f13/0x2370CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.5.0-rc4-rt2-yocto-preempt-rt+ #15Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x68/0xb0 dump_stack+0x14/0x20 __might_resched+0x1aa/0x280 ? __pfx_rcu_torture_err_cb+0x10/0x10 rt_spin_lock+0x53/0x130 ? find_vmap_area+0x1f/0x70 find_vmap_area+0x1f/0x70 vmalloc_dump_obj+0x20/0x60 mem_dump_obj+0x22/0x90 __call_rcu_common+0x5bf/0x940 ? debug_smp_processor_id+0x1b/0x30 call_rcu_hurry+0x14/0x20 rcu_torture_init+0x1f82/0x2370 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_leak_cb+0x10/0x10 ? __pfx_rcu_torture_init+0x10/0x10 do_one_initcall+0x6c/0x300 ? debug_smp_processor_id+0x1b/0x30 kernel_init_freeable+0x2b9/0x540 ? __pfx_kernel_init+0x10/0x10 kernel_init+0x1f/0x150 ret_from_fork+0x40/0x50 ? __pfx_kernel_init+0x10/0x10 ret_from_fork_asm+0x1b/0x30 The previous patch fixes this by using the deadlock-safe best-effortversion of find_vm_area. However, in case of failure print the fact thatthe pointer was a vmalloc pointer so that we print at least something.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nsh: Use correct mac_offset to unwind gso skb in nsh_gso_segment()As the call trace shows, skb_panic was caused by wrong skb->mac_headerin nsh_gso_segment():invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 PID: 2737 Comm: syz Not tainted 6.3.0-next-20230505 #1RIP: 0010:skb_panic+0xda/0xe0call Trace: skb_push+0x91/0xa0 nsh_gso_segment+0x4f3/0x570 skb_mac_gso_segment+0x19e/0x270 __skb_gso_segment+0x1e8/0x3c0 validate_xmit_skb+0x452/0x890 validate_xmit_skb_list+0x99/0xd0 sch_direct_xmit+0x294/0x7c0 __dev_queue_xmit+0x16f0/0x1d70 packet_xmit+0x185/0x210 packet_snd+0xc15/0x1170 packet_sendmsg+0x7b/0xa0 sock_sendmsg+0x14f/0x160The root cause is:nsh_gso_segment() use skb->network_header - nhoff to reset mac_headerin skb_gso_error_unwind() if inner-layer protocol gso fails.However, skb->network_header may be reset by inner-layer protocolgso function e.g. mpls_gso_segment. skb->mac_header reset by theinaccurate network_header will be larger than skb headroom.nsh_gso_segment nhoff = skb->network_header - skb->mac_header; __skb_pull(skb,nsh_len) skb_mac_gso_segment mpls_gso_segment skb_reset_network_header(skb);//skb->network_header+=nsh_len return -EINVAL; skb_gso_error_unwind skb_push(skb, nsh_len); skb->mac_header = skb->network_header - nhoff; // skb->mac_header > skb->headroom, cause skb_push panicUse correct mac_offset to restore mac_header and get rid of nhoff.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix incorrect splitting in btrfs_drop_extent_map_rangeIn production we were seeing a variety of WARN_ON()'s in the extent_mapcode, specifically in btrfs_drop_extent_map_range() when we have to calladd_extent_mapping() for our second split.Consider the following extent map layout PINNED [0 16K) [32K, 48K)and then we call btrfs_drop_extent_map_range for [0, 36K), withskip_pinned == true. The initial loop will have start = 0 end = 36K len = 36Kwe will find the [0, 16k) extent, but since we are pinned we will skipit, which has this code start = em_end; if (end != (u64)-1) len = start + len - em_end;em_end here is 16K, so now the values are start = 16K len = 16K + 36K - 16K = 36Klen should instead be 20K. This is a problem when we find the nextextent at [32K, 48K), we need to split this extent to leave [36K, 48k),however the code for the split looks like this split->start = start + len; split->len = em_end - (start + len);In this case we have em_end = 48K split->start = 16K + 36K // this should be 16K + 20K split->len = 48K - (16K + 36K) // this overflows as 16K + 36K is 52Kand now we have an invalid extent_map in the tree that potentiallyoverlaps other entries in the extent map. Even in the non-overlappingcase we will have split->start set improperly, which will cause problemswith any block related calculations.We don't actually need len in this loop, we can simply use end as ourend point, and only adjust start up when we find a pinned extent we needto skip.Adjust the logic to do this, which keeps us from inserting an invalidextent map.We only skip_pinned in the relocation case, so this is relatively rare,except in the case where you are running relocation a lot, which canhappen with auto relocation on.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to drop all dirty pages during umount() if cp_error is setxfstest generic/361 reports a bug as below:f2fs_bug_on(sbi, sbi->fsync_node_num);kernel BUG at fs/f2fs/super.c:1627!RIP: 0010:f2fs_put_super+0x3a8/0x3b0Call Trace: generic_shutdown_super+0x8c/0x1b0 kill_block_super+0x2b/0x60 kill_f2fs_super+0x87/0x110 deactivate_locked_super+0x39/0x80 deactivate_super+0x46/0x50 cleanup_mnt+0x109/0x170 __cleanup_mnt+0x16/0x20 task_work_run+0x65/0xa0 exit_to_user_mode_prepare+0x175/0x190 syscall_exit_to_user_mode+0x25/0x50 do_syscall_64+0x4c/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdcDuring umount(), if cp_error is set, f2fs_wait_on_all_pages() shouldnot stop waiting all F2FS_WB_CP_DATA pages to be writebacked, otherwise,fsync_node_num can be non-zero after f2fs_wait_on_all_pages() causingthis bug.In this case, to avoid deadloop in f2fs_wait_on_all_pages(), it needsto drop all dirty pages rather than redirtying them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation for lmac typeUpon physical link change, firmware reports to the kernel about thechange along with the details like speed, lmac_type_id, etc.Kernel derives lmac_type based on lmac_type_id received from firmware.In a few scenarios, firmware returns an invalid lmac_type_id, whichis resulting in below kernel panic. This patch adds the missingvalidation of the lmac_type_id field.Internal error: Oops: 96000005 [#1] PREEMPT SMP[ 35.321595] Modules linked in:[ 35.328982] CPU: 0 PID: 31 Comm: kworker/0:1 Not tainted5.4.210-g2e3169d8e1bc-dirty #17[ 35.337014] Hardware name: Marvell CN103XX board (DT)[ 35.344297] Workqueue: events work_for_cpu_fn[ 35.352730] pstate: 40400089 (nZcv daIf +PAN -UAO)[ 35.360267] pc : strncpy+0x10/0x30[ 35.366595] lr : cgx_link_change_handler+0x90/0x180

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54132 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: stop parsing non-compact HEAD index if clusterofs is invalidSyzbot generated a crafted image [1] with a non-compact HEAD index ofclusterofs 33024 while valid numbers should be 0 ~ lclustersize-1,which causes the following unexpected behavior as below: BUG: unable to handle page fault for address: fffff52101a3fff9 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 23ffed067 P4D 23ffed067 PUD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 4398 Comm: kworker/u5:1 Not tainted 6.3.0-rc6-syzkaller-g09a9639e56c0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/30/2023 Workqueue: erofs_worker z_erofs_decompressqueue_work RIP: 0010:z_erofs_decompress_queue+0xb7e/0x2b40 ... Call Trace: z_erofs_decompressqueue_work+0x99/0xe0 process_one_work+0x8f6/0x1170 worker_thread+0xa63/0x1210 kthread+0x270/0x300 ret_from_fork+0x1f/0x30Note that normal images or images using compact indexes are notimpacted. Let's fix this now.[1] https://lore.kernel.org/r/000000000000ec75b005ee97fbaa@google.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54155 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: core: remove unnecessary frame_sz check in bpf_xdp_adjust_tail()Syzkaller reported the following issue:=======================================Too BIG xdp->frame_sz = 131072WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 ____bpf_xdp_adjust_tail net/core/filter.c:4121 [inline]WARNING: CPU: 0 PID: 5020 at net/core/filter.c:4121 bpf_xdp_adjust_tail+0x466/0xa10 net/core/filter.c:4103...Call Trace: bpf_prog_4add87e5301a4105+0x1a/0x1c __bpf_prog_run include/linux/filter.h:600 [inline] bpf_prog_run_xdp include/linux/filter.h:775 [inline] bpf_prog_run_generic_xdp+0x57e/0x11e0 net/core/dev.c:4721 netif_receive_generic_xdp net/core/dev.c:4807 [inline] do_xdp_generic+0x35c/0x770 net/core/dev.c:4866 tun_get_user+0x2340/0x3ca0 drivers/net/tun.c:1919 tun_chr_write_iter+0xe8/0x210 drivers/net/tun.c:2043 call_write_iter include/linux/fs.h:1871 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x650/0xe40 fs/read_write.c:584 ksys_write+0x12f/0x250 fs/read_write.c:637 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdxdp->frame_sz > PAGE_SIZE check was introduced in commit c8741e2bfe87("xdp: Allow bpf_xdp_adjust_tail() to grow packet size"). But JesperDangaard Brouer noted that after introducing thexdp_init_buff() which all XDP driver use - it's safe to remove thischeck. The original intend was to catch cases where XDP drivers havenot been updated to use xdp.frame_sz, but that is not longer a concern(since xdp_init_buff).Running the initial syzkaller repro it was discovered that thecontiguous physical memory allocation is used for both xdp paths intun_get_user(), e.g. tun_build_skb() and tun_alloc_skb(). It was alsostated by Jesper Dangaard Brouer that XDP canwork on higher order pages, as long as this is contiguous physicalmemory (e.g. a page).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54160 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_sdei: Fix sleep from invalid context BUGRunning a preempt-rt (v6.2-rc3-rt1) based kernel on an Ampere Altratriggers: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 24, name: cpuhp/0 preempt_count: 0, expected: 0 RCU nest depth: 0, expected: 0 3 locks held by cpuhp/0/24: #0: ffffda30217c70d0 (cpu_hotplug_lock){++++}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #1: ffffda30217c7120 (cpuhp_state-up){+.+.}-{0:0}, at: cpuhp_thread_fun+0x5c/0x248 #2: ffffda3021c711f0 (sdei_list_lock){....}-{3:3}, at: sdei_cpuhp_up+0x3c/0x130 irq event stamp: 36 hardirqs last enabled at (35): [] finish_task_switch+0xb4/0x2b0 hardirqs last disabled at (36): [] cpuhp_thread_fun+0x21c/0x248 softirqs last enabled at (0): [] copy_process+0x63c/0x1ac0 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 0 PID: 24 Comm: cpuhp/0 Not tainted 5.19.0-rc3-rt5-[...] Hardware name: WIWYNN Mt.Jade Server [...] Call trace: dump_backtrace+0x114/0x120 show_stack+0x20/0x70 dump_stack_lvl+0x9c/0xd8 dump_stack+0x18/0x34 __might_resched+0x188/0x228 rt_spin_lock+0x70/0x120 sdei_cpuhp_up+0x3c/0x130 cpuhp_invoke_callback+0x250/0xf08 cpuhp_thread_fun+0x120/0x248 smpboot_thread_fn+0x280/0x320 kthread+0x130/0x140 ret_from_fork+0x10/0x20sdei_cpuhp_up() is called in the STARTING hotplug section,which runs with interrupts disabled. Use a CPUHP_AP_ONLINE_DYN entryinstead to execute the cpuhp cb later, with preemption enabled.SDEI originally got its own cpuhp slot to allow interactingwith perf. It got superseded by pNMI and this early slot is notrelevant anymore. [1]Some SDEI calls (e.g. SDEI_1_0_FN_SDEI_PE_MASK) take actions on thecalling CPU. It is checked that preemption is disabled for them._ONLINE cpuhp cb are executed in the 'per CPU hotplug thread'.Preemption is enabled in those threads, but their cpumask is limitedto 1 CPU.Move 'WARN_ON_ONCE(preemptible())' statements so that SDEI cpuhp cbdon't trigger them.Also add a check for the SDEI_1_0_FN_SDEI_PRIVATE_RESET SDEI callwhich acts on the calling CPU.[1]:https://lore.kernel.org/all/5813b8c5-ae3e-87fd-fccc-94c9cd08816d@arm.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54170 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:keys: Fix linking a duplicate key to a keyring's assoc_arrayWhen making a DNS query inside the kernel using dns_query(), the requestcode can in rare cases end up creating a duplicate index key in theassoc_array of the destination keyring. It is eventually found bya BUG_ON() check in the assoc_array implementation and results ina crash.Example report:[2158499.700025] kernel BUG at ../lib/assoc_array.c:652![2158499.700039] invalid opcode: 0000 [#1] SMP PTI[2158499.700065] CPU: 3 PID: 31985 Comm: kworker/3:1 Kdump: loaded Not tainted 5.3.18-150300.59.90-default #1 SLE15-SP3[2158499.700096] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020[2158499.700351] Workqueue: cifsiod cifs_resolve_server [cifs][2158499.700380] RIP: 0010:assoc_array_insert+0x85f/0xa40[2158499.700401] Code: ff 74 2b 48 8b 3b 49 8b 45 18 4c 89 e6 48 83 e7 fe e8 95 ec 74 00 3b 45 88 7d db 85 c0 79 d4 0f 0b 0f 0b 0f 0b e8 41 f2 be ff <0f> 0b 0f 0b 81 7d 88 ff ff ff 7f 4c 89 eb 4c 8b ad 58 ff ff ff 0f[2158499.700448] RSP: 0018:ffffc0bd6187faf0 EFLAGS: 00010282[2158499.700470] RAX: ffff9f1ea7da2fe8 RBX: ffff9f1ea7da2fc1 RCX: 0000000000000005[2158499.700492] RDX: 0000000000000000 RSI: 0000000000000005 RDI: 0000000000000000[2158499.700515] RBP: ffffc0bd6187fbb0 R08: ffff9f185faf1100 R09: 0000000000000000[2158499.700538] R10: ffff9f1ea7da2cc0 R11: 000000005ed8cec8 R12: ffffc0bd6187fc28[2158499.700561] R13: ffff9f15feb8d000 R14: ffff9f1ea7da2fc0 R15: ffff9f168dc0d740[2158499.700585] FS: 0000000000000000(0000) GS:ffff9f185fac0000(0000) knlGS:0000000000000000[2158499.700610] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[2158499.700630] CR2: 00007fdd94fca238 CR3: 0000000809d8c006 CR4: 00000000003706e0[2158499.700702] Call Trace:[2158499.700741] ? key_alloc+0x447/0x4b0[2158499.700768] ? __key_link_begin+0x43/0xa0[2158499.700790] __key_link_begin+0x43/0xa0[2158499.700814] request_key_and_link+0x2c7/0x730[2158499.700847] ? dns_resolver_read+0x20/0x20 [dns_resolver][2158499.700873] ? key_default_cmp+0x20/0x20[2158499.700898] request_key_tag+0x43/0xa0[2158499.700926] dns_query+0x114/0x2ca [dns_resolver][2158499.701127] dns_resolve_server_name_to_ip+0x194/0x310 [cifs][2158499.701164] ? scnprintf+0x49/0x90[2158499.701190] ? __switch_to_asm+0x40/0x70[2158499.701211] ? __switch_to_asm+0x34/0x70[2158499.701405] reconn_set_ipaddr_from_hostname+0x81/0x2a0 [cifs][2158499.701603] cifs_resolve_server+0x4b/0xd0 [cifs][2158499.701632] process_one_work+0x1f8/0x3e0[2158499.701658] worker_thread+0x2d/0x3f0[2158499.701682] ? process_one_work+0x3e0/0x3e0[2158499.701703] kthread+0x10d/0x130[2158499.701723] ? kthread_park+0xb0/0xb0[2158499.701746] ret_from_fork+0x1f/0x40The situation occurs as follows:* Some kernel facility invokes dns_query() to resolve a hostname, for example, "abcdef". The function registers its global DNS resolver cache as current->cred.thread_keyring and passes the query to request_key_net() -> request_key_tag() -> request_key_and_link().* Function request_key_and_link() creates a keyring_search_context object. Its match_data.cmp method gets set via a call to type->match_preparse() (resolves to dns_resolver_match_preparse()) to dns_resolver_cmp().* Function request_key_and_link() continues and invokes search_process_keyrings_rcu() which returns that a given key was not found. The control is then passed to request_key_and_link() -> construct_alloc_key().* Concurrently to that, a second task similarly makes a DNS query for "abcdef." and its result gets inserted into the DNS resolver cache.* Back on the first task, function construct_alloc_key() first runs __key_link_begin() to determine an assoc_array_edit operation to insert a new key. Index keys in the array are compared exactly as-is, using keyring_compare_object(). The operation ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54171 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix memory leak of iter->temp when reading trace_pipekmemleak reports: unreferenced object 0xffff88814d14e200 (size 256): comm "cat", pid 336, jiffies 4294871818 (age 779.490s) hex dump (first 32 bytes): 04 00 01 03 00 00 00 00 08 00 00 00 00 00 00 00 ................ 0c d8 c8 9b ff ff ff ff 04 5a ca 9b ff ff ff ff .........Z...... backtrace: [] __kmalloc+0x4f/0x140 [] trace_find_next_entry+0xbb/0x1d0 [] trace_print_lat_context+0xaf/0x4e0 [] print_trace_line+0x3e0/0x950 [] tracing_read_pipe+0x2d9/0x5a0 [] vfs_read+0x143/0x520 [] ksys_read+0xbd/0x160 [] do_syscall_64+0x3f/0x90 [] entry_SYSCALL_64_after_hwframe+0x6e/0xd8when reading file 'trace_pipe', 'iter->temp' is allocated or relocatedin trace_find_next_entry() but not freed before 'trace_pipe' is closed.To fix it, free 'iter->temp' in tracing_release_pipe().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54178 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: unittest: fix null pointer dereferencing in of_unittest_find_node_by_name()when kmalloc() fail to allocate memory in kasprintf(), nameor full_name will be NULL, strcmp() will causenull pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54181 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix issue in verifying allow_ptr_leaksAfter we converted the capabilities of our networking-bpf program fromcap_sys_admin to cap_net_admin+cap_bpf, our networking-bpf programfailed to start. Because it failed the bpf verifier, and the error logis "R3 pointer comparison prohibited".A simple reproducer as follows,SEC("cls-ingress")int ingress(struct __sk_buff *skb){ struct iphdr *iph = (void *)(long)skb->data + sizeof(struct ethhdr); if ((long)(iph + 1) > (long)skb->data_end) return TC_ACT_STOLEN; return TC_ACT_OK;}Per discussion with Yonghong and Alexei [1], comparison of two packetpointers is not a pointer leak. This patch fixes it.Our local kernel is 6.1.y and we expect this fix to be backported to6.1.y, so stable is CCed.[1]. https://lore.kernel.org/bpf/CAADnVQ+Nmspr7Si+pxWn8zkE7hX-7s93ugwC+94aXSy4uQ9vBg@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsit: Free cmds before session freeCommands from recovery entries are freed after session has been closed.That leads to use-after-free at command free or NPE with such call trace:Time2Retain timer expired for SID: 1, cleaning up iSCSI session.BUG: kernel NULL pointer dereference, address: 0000000000000140RIP: 0010:sbitmap_queue_clear+0x3a/0xa0Call Trace: target_release_cmd_kref+0xd1/0x1f0 [target_core_mod] transport_generic_free_cmd+0xd1/0x180 [target_core_mod] iscsit_free_cmd+0x53/0xd0 [iscsi_target_mod] iscsit_free_connection_recovery_entries+0x29d/0x320 [iscsi_target_mod] iscsit_close_session+0x13a/0x140 [iscsi_target_mod] iscsit_check_post_dataout+0x440/0x440 [iscsi_target_mod] call_timer_fn+0x24/0x140Move cleanup of recovery enrties to before session freeing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: Fix oops for port->pm on uart_change_pm()Unloading a hardware specific 8250 driver can produce error "Unable tohandle kernel paging request at virtual address" about ten seconds afterunloading the driver. This happens on uart_hangup() callinguart_change_pm().Turns out commit 04e82793f068 ("serial: 8250: Reinit port->pm on portspecific driver unbind") was only a partial fix. If the hardware specificdriver has initialized port->pm function, we need to clear port->pm too.Just reinitializing port->ops does not do this. Otherwise serial8250_pm()will call port->pm() instead of serial8250_do_pm().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix potential panic dues to unprotected smc_llc_srv_add_link()There is a certain chance to trigger the following panic:PID: 5900 TASK: ffff88c1c8af4100 CPU: 1 COMMAND: "kworker/1:48" #0 [ffff9456c1cc79a0] machine_kexec at ffffffff870665b7 #1 [ffff9456c1cc79f0] __crash_kexec at ffffffff871b4c7a #2 [ffff9456c1cc7ab0] crash_kexec at ffffffff871b5b60 #3 [ffff9456c1cc7ac0] oops_end at ffffffff87026ce7 #4 [ffff9456c1cc7ae0] page_fault_oops at ffffffff87075715 #5 [ffff9456c1cc7b58] exc_page_fault at ffffffff87ad0654 #6 [ffff9456c1cc7b80] asm_exc_page_fault at ffffffff87c00b62 [exception RIP: ib_alloc_mr+19] RIP: ffffffffc0c9cce3 RSP: ffff9456c1cc7c38 RFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000004 RDX: 0000000000000010 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff88c1ea281d00 R8: 000000020a34ffff R9: ffff88c1350bbb20 R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000 R13: 0000000000000010 R14: ffff88c1ab040a50 R15: ffff88c1ea281d00 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffff9456c1cc7c60] smc_ib_get_memory_region at ffffffffc0aff6df [smc] #8 [ffff9456c1cc7c88] smcr_buf_map_link at ffffffffc0b0278c [smc] #9 [ffff9456c1cc7ce0] __smc_buf_create at ffffffffc0b03586 [smc]The reason here is that when the server tries to create a second link,smc_llc_srv_add_link() has no protection and may add a new link tolink group. This breaks the security environment protected byllc_conf_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54240 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: mtk_eth_soc: fix possible NULL pointer dereference in mtk_hwlro_get_fdir_all()rule_locs is allocated in ethtool_get_rxnfc and the size is determined byrule_cnt from user space. So rule_cnt needs to be check before usingrule_locs to avoid NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcuscale: Move rcu_scale_writer() schedule_timeout_uninterruptible() to _idle()The rcuscale.holdoff module parameter can be used to delay the startof rcu_scale_writer() kthread. However, the hung-task timeout willtrigger when the timeout specified by rcuscale.holdoff is greater thanhung_task_timeout_secs:runqemu kvm nographic slirp qemuparams="-smp 4 -m 2048M"bootparams="rcuscale.shutdown=0 rcuscale.holdoff=300"[ 247.071753] INFO: task rcu_scale_write:59 blocked for more than 122 seconds.[ 247.072529] Not tainted 6.4.0-rc1-00134-gb9ed6de8d4ff #7[ 247.073400] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 247.074331] task:rcu_scale_write state:D stack:30144 pid:59 ppid:2 flags:0x00004000[ 247.075346] Call Trace:[ 247.075660] [ 247.075965] __schedule+0x635/0x1280[ 247.076448] ? __pfx___schedule+0x10/0x10[ 247.076967] ? schedule_timeout+0x2dc/0x4d0[ 247.077471] ? __pfx_lock_release+0x10/0x10[ 247.078018] ? enqueue_timer+0xe2/0x220[ 247.078522] schedule+0x84/0x120[ 247.078957] schedule_timeout+0x2e1/0x4d0[ 247.079447] ? __pfx_schedule_timeout+0x10/0x10[ 247.080032] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.080591] ? __pfx_process_timeout+0x10/0x10[ 247.081163] ? __pfx_sched_set_fifo_low+0x10/0x10[ 247.081760] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.082287] rcu_scale_writer+0x6b1/0x7f0[ 247.082773] ? mark_held_locks+0x29/0xa0[ 247.083252] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.083865] ? __pfx_rcu_scale_writer+0x10/0x10[ 247.084412] kthread+0x179/0x1c0[ 247.084759] ? __pfx_kthread+0x10/0x10[ 247.085098] ret_from_fork+0x2c/0x50[ 247.085433] This commit therefore replaces schedule_timeout_uninterruptible() withschedule_timeout_idle().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: Limit TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME to INT_MAX.syzkaller found zero division error [0] in div_s64_rem() called fromget_cycle_time_elapsed(), where sched->cycle_time is the divisor.We have tests in parse_taprio_schedule() so that cycle_time will neverbe 0, and actually cycle_time is not 0 in get_cycle_time_elapsed().The problem is that the types of divisor are different; cycle_time iss64, but the argument of div_s64_rem() is s32.syzkaller fed this input and 0x100000000 is cast to s32 to be 0. @TCA_TAPRIO_ATTR_SCHED_CYCLE_TIME={0xc, 0x8, 0x100000000}We use s64 for cycle_time to cast it to ktime_t, so let's keep it andset max for cycle_time.While at it, we prevent overflow in setup_txtime() and add anothertest in parse_taprio_schedule() to check if cycle_time overflows.Also, we add a new tdc test case for this issue.[0]:divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 103 Comm: kworker/1:3 Not tainted 6.5.0-rc1-00330-g60cc1f7d0605 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: ipv6_addrconf addrconf_dad_workRIP: 0010:div_s64_rem include/linux/math64.h:42 [inline]RIP: 0010:get_cycle_time_elapsed net/sched/sch_taprio.c:223 [inline]RIP: 0010:find_entry_to_transmit+0x252/0x7e0 net/sched/sch_taprio.c:344Code: 3c 02 00 0f 85 5e 05 00 00 48 8b 4c 24 08 4d 8b bd 40 01 00 00 48 8b 7c 24 48 48 89 c8 4c 29 f8 48 63 f7 48 99 48 89 74 24 70 <48> f7 fe 48 29 d1 48 8d 04 0f 49 89 cc 48 89 44 24 20 49 8d 85 10RSP: 0018:ffffc90000acf260 EFLAGS: 00010206RAX: 177450e0347560cf RBX: 0000000000000000 RCX: 177450e0347560cfRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000100000000RBP: 0000000000000056 R08: 0000000000000000 R09: ffffed10020a0934R10: ffff8880105049a7 R11: ffff88806cf3a520 R12: ffff888010504800R13: ffff88800c00d800 R14: ffff8880105049a0 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff88806cf00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0edf84f0e8 CR3: 000000000d73c002 CR4: 0000000000770ee0PKRU: 55555554Call Trace: get_packet_txtime net/sched/sch_taprio.c:508 [inline] taprio_enqueue_one+0x900/0xff0 net/sched/sch_taprio.c:577 taprio_enqueue+0x378/0xae0 net/sched/sch_taprio.c:658 dev_qdisc_enqueue+0x46/0x170 net/core/dev.c:3732 __dev_xmit_skb net/core/dev.c:3821 [inline] __dev_queue_xmit+0x1b2f/0x3000 net/core/dev.c:4169 dev_queue_xmit include/linux/netdevice.h:3088 [inline] neigh_resolve_output net/core/neighbour.c:1552 [inline] neigh_resolve_output+0x4a7/0x780 net/core/neighbour.c:1532 neigh_output include/net/neighbour.h:544 [inline] ip6_finish_output2+0x924/0x17d0 net/ipv6/ip6_output.c:135 __ip6_finish_output+0x620/0xaa0 net/ipv6/ip6_output.c:196 ip6_finish_output net/ipv6/ip6_output.c:207 [inline] NF_HOOK_COND include/linux/netfilter.h:292 [inline] ip6_output+0x206/0x410 net/ipv6/ip6_output.c:228 dst_output include/net/dst.h:458 [inline] NF_HOOK.constprop.0+0xea/0x260 include/linux/netfilter.h:303 ndisc_send_skb+0x872/0xe80 net/ipv6/ndisc.c:508 ndisc_send_ns+0xb5/0x130 net/ipv6/ndisc.c:666 addrconf_dad_work+0xc14/0x13f0 net/ipv6/addrconf.c:4175 process_one_work+0x92c/0x13a0 kernel/workqueue.c:2597 worker_thread+0x60f/0x1240 kernel/workqueue.c:2748 kthread+0x2fe/0x3f0 kernel/kthread.c:389 ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308 Modules linked in:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix potential oops in cifs_oplock_breakWith deferred close we can have closes that race with lease breaks,and so with the current checks for whether to send the lease response,oplock_response(), this can mean that an unmount (kill_sb) can occurjust before we were checking if the tcon->ses is valid. See below:[Fri Aug 4 04:12:50 2023] RIP: 0010:cifs_oplock_break+0x1f7/0x5b0 [cifs][Fri Aug 4 04:12:50 2023] Code: 7d a8 48 8b 7d c0 c0 e9 02 48 89 45 b8 41 89 cf e8 3e f5 ff ff 4c 89 f7 41 83 e7 01 e8 82 b3 03 f2 49 8b 45 50 48 85 c0 74 5e <48> 83 78 60 00 74 57 45 84 ff 75 52 48 8b 43 98 48 83 eb 68 48 39[Fri Aug 4 04:12:50 2023] RSP: 0018:ffffb30607ddbdf8 EFLAGS: 00010206[Fri Aug 4 04:12:50 2023] RAX: 632d223d32612022 RBX: ffff97136944b1e0 RCX: 0000000080100009[Fri Aug 4 04:12:50 2023] RDX: 0000000000000001 RSI: 0000000080100009 RDI: ffff97136944b188[Fri Aug 4 04:12:50 2023] RBP: ffffb30607ddbe58 R08: 0000000000000001 R09: ffffffffc08e0900[Fri Aug 4 04:12:50 2023] R10: 0000000000000001 R11: 000000000000000f R12: ffff97136944b138[Fri Aug 4 04:12:50 2023] R13: ffff97149147c000 R14: ffff97136944b188 R15: 0000000000000000[Fri Aug 4 04:12:50 2023] FS: 0000000000000000(0000) GS:ffff9714f7c00000(0000) knlGS:0000000000000000[Fri Aug 4 04:12:50 2023] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[Fri Aug 4 04:12:50 2023] CR2: 00007fd8de9c7590 CR3: 000000011228e000 CR4: 0000000000350ef0[Fri Aug 4 04:12:50 2023] Call Trace:[Fri Aug 4 04:12:50 2023] [Fri Aug 4 04:12:50 2023] process_one_work+0x225/0x3d0[Fri Aug 4 04:12:50 2023] worker_thread+0x4d/0x3e0[Fri Aug 4 04:12:50 2023] ? process_one_work+0x3d0/0x3d0[Fri Aug 4 04:12:50 2023] kthread+0x12a/0x150[Fri Aug 4 04:12:50 2023] ? set_kthread_struct+0x50/0x50[Fri Aug 4 04:12:50 2023] ret_from_fork+0x22/0x30[Fri Aug 4 04:12:50 2023] To fix this change the ordering of the checks before sending the oplock_responseto first check if the openFileList is empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/kms/nv50-: init hpd_irq_lock for PIOR DPFixes OOPS on boards with ANX9805 DP encoders.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: release path before inode lookup during the ino lookup ioctlDuring the ino lookup ioctl we can end up calling btrfs_iget() to get aninode reference while we are holding on a root's btree. If btrfs_iget()needs to lookup the inode from the root's btree, because it's notcurrently loaded in memory, then it will need to lock another or thesame path in the same root btree. This may result in a deadlock andtrigger the following lockdep splat: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted ------------------------------------------------------ syz-executor277/5012 is trying to acquire lock: ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 but task is already holding lock: ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302 btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955 btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline] btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338 btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline] open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494 btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154 btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 fc_mount fs/namespace.c:1112 [inline] vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142 btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579 legacy_get_tree+0xef/0x190 fs/fs_context.c:611 vfs_get_tree+0x8c/0x270 fs/super.c:1519 do_new_mount+0x28f/0xae0 fs/namespace.c:3335 do_mount fs/namespace.c:3675 [inline] __do_sys_mount fs/namespace.c:3884 [inline] __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #0 (btrfs-tree-01){++++}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645 __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136 btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline] btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281 btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline] btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412 btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline] btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716 btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline] btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105 btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: avoid hanging tasks on the tx_locksyzbot sent a hung task report and Eric explains that adversarialreceiver may keep RWIN at 0 for a long time, so we are not guaranteedto make forward progress. Thread which took tx_lock and went to sleepmay not release tx_lock for hours. Use interruptible sleep wherepossible and reschedule the work if it can't take the lock.Testing: existing selftest passes

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54314 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: af9005: Fix null-ptr-deref in af9005_i2c_xferIn af9005_i2c_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9005_i2c_xfer. If accessingmsg[i].buf[0] without sanity check, null ptr deref would happen.We add check on msg[i].len to prevent crash.Similar commit:commit 0ed554fd769a("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: use smc_lgr_list.lock to protect smc_lgr_list.list iterate in smcr_port_addWhile doing smcr_port_add, there maybe linkgroup add into or deletefrom smc_lgr_list.list at the same time, which may result kernel crash.So, use smc_lgr_list.lock to protect smc_lgr_list.list iterate insmcr_port_add.The crash calltrace show below:BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 0 PID: 559726 Comm: kworker/0:92 Kdump: loaded Tainted: GHardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 449e491 04/01/2014Workqueue: events smc_ib_port_event_work [smc]RIP: 0010:smcr_port_add+0xa6/0xf0 [smc]RSP: 0000:ffffa5a2c8f67de0 EFLAGS: 00010297RAX: 0000000000000001 RBX: ffff9935e0650000 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffff9935e0654290 RDI: ffff9935c8560000RBP: 0000000000000000 R08: 0000000000000000 R09: ffff9934c0401918R10: 0000000000000000 R11: ffffffffb4a5c278 R12: ffff99364029aae4R13: ffff99364029aa00 R14: 00000000ffffffed R15: ffff99364029ab08FS: 0000000000000000(0000) GS:ffff994380600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 0000000f06a10003 CR4: 0000000002770ef0PKRU: 55555554Call Trace: smc_ib_port_event_work+0x18f/0x380 [smc] process_one_work+0x19b/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x114/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54323 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxl/pmem: Fix nvdimm registration racesA loop of the form: while true; do modprobe cxl_pci; modprobe -r cxl_pci; done...fails with the following crash signature: BUG: kernel NULL pointer dereference, address: 0000000000000040 [..] RIP: 0010:cxl_internal_send_cmd+0x5/0xb0 [cxl_core] [..] Call Trace: cxl_pmem_ctl+0x121/0x240 [cxl_pmem] nvdimm_get_config_data+0xd6/0x1a0 [libnvdimm] nd_label_data_init+0x135/0x7e0 [libnvdimm] nvdimm_probe+0xd6/0x1c0 [libnvdimm] nvdimm_bus_probe+0x7a/0x1e0 [libnvdimm] really_probe+0xde/0x380 __driver_probe_device+0x78/0x170 driver_probe_device+0x1f/0x90 __device_attach_driver+0x85/0x110 bus_for_each_drv+0x7d/0xc0 __device_attach+0xb4/0x1e0 bus_probe_device+0x9f/0xc0 device_add+0x445/0x9c0 nd_async_device_register+0xe/0x40 [libnvdimm] async_run_entry_fn+0x30/0x130...namely that the bottom half of async nvdimm device registration runsafter the CXL has already torn down the context that cxl_pmem_ctl()needs. Unlike the ACPI NFIT case that benefits from launching multiplenvdimm device registrations in parallel from those listed in the table,CXL is already marked PROBE_PREFER_ASYNCHRONOUS. So provide for asynchronous registration path to preclude this scenario.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7324 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ses: Fix possible addl_desc_ptr out-of-bounds accessesSanitize possible addl_desc_ptr out-of-bounds accesses inses_enclosure_data_process().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2193 Severity: Moderate CVSS3 score: 5.5

Description: A Speculative Race Condition (SRC) vulnerability that impacts modern CPU architectures supporting speculative execution (related to Spectre V1) has been disclosed. An unauthenticated attacker can exploit this vulnerability to disclose arbitrary data from the CPU using race conditions to access the speculative executable code paths.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-22365 Severity: Moderate CVSS3 score: 5.5

Description: linux-pam (aka Linux PAM) before 1.6.0 allows attackers to cause a denial of service (blocked login process) via mkfifo because the openat call (for protect_dir) lacks O_DIRECTORY.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
pam > 0-0 (version in image is 1.3.0-150000.6.86.1).

CVE-2024-23849 Severity: Moderate CVSS3 score: 5.5

Description: In rds_recv_track_latency in net/rds/af_rds.c in the Linux kernel through 6.7.1, there is an off-by-one error for an RDS_MSG_RX_DGRAM_TRACE_MAX comparison, resulting in out-of-bounds access.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-24860 Severity: Moderate CVSS3 score: 5.5

Description: A race condition was found in the Linux kernel's bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test: smc_run nginx smc_run wrk -t 16 -c 1000 -d -H 'Connection: Close' - continuously dump SMC-D connections in parallel: watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G E 6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace: ? __die+0x24/0x70 ? page_fault_oops+0x66/0x150 ? exc_page_fault+0x69/0x140 ? asm_exc_page_fault+0x26/0x30 ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] ? __kmalloc_node_track_caller+0x35d/0x430 ? __alloc_skb+0x77/0x170 smc_diag_dump_proto+0xd0/0xf0 [smc_diag] smc_diag_dump+0x26/0x60 [smc_diag] netlink_dump+0x19f/0x320 __netlink_dump_start+0x1dc/0x300 smc_diag_handler_dump+0x6a/0x80 [smc_diag] ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag] sock_diag_rcv_msg+0x121/0x140 ? __pfx_sock_diag_rcv_msg+0x10/0x10 netlink_rcv_skb+0x5a/0x110 sock_diag_rcv+0x28/0x40 netlink_unicast+0x22a/0x330 netlink_sendmsg+0x1f8/0x420 __sock_sendmsg+0xb0/0xc0 ____sys_sendmsg+0x24e/0x300 ? copy_msghdr_from_user+0x62/0x80 ___sys_sendmsg+0x7c/0xd0 ? __do_fault+0x34/0x160 ? do_read_fault+0x5f/0x100 ? do_fault+0xb0/0x110 ? __handle_mm_fault+0x2b0/0x6c0 __sys_sendmsg+0x4d/0x80 do_syscall_64+0x69/0x180 entry_SYSCALL_64_after_hwframe+0x6e/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn->rmb_desc. So fix it by checking before dump.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26625 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: call sock_orphan() at release timesyzbot reported an interesting trace [1] caused by a stale sk->sk_wqpointer in a closed llc socket.In commit ff7b11aa481f ("net: socket: set sock->sk to NULL aftercalling proto_ops::release()") Eric Biggers hinted that some protocolsare missing a sock_orphan(), we need to perform a full audit.In net-next, I plan to clear sock->sk from sock_orphan() andamend Eric patch to add a warning.[1] BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline] BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline] BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline] BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/list.h:373 [inline] waitqueue_active include/linux/wait.h:127 [inline] sock_def_write_space_wfree net/core/sock.c:3384 [inline] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [inline] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline] e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801 __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [inline] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c:388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Allocated by task 5167: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [inline] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3813 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3019 [inline] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net/socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x14c/0x260 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bFreed by task 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 poison_slab_object mm/kasan/common.c:241 [inline] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2121 [inlin---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with hostlock every time for deciding if error handler kthread needs to be waken up.This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor the last in-flight request, scsi_host_busy() has been run for (N * M -1) times, and request has been iterated for (N*M - 1) * (N * M) times.If both N and M are big enough, hard lockup can be triggered on acquiringhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).Fix the issue by calling scsi_host_busy() outside the host lock. We don'tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary 'busy' variables pointed out by Bart]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26631 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_workidev->mc_ifc_count can be written over without proper locking.Originally found by syzbot [1], fix this issue by encapsulating callsto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) withmutex_lock() and mutex_unlock() accordingly as these functionsshould only be called with mc_lock per their declarations.[1]BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_workwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ...write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26636 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: make llc_ui_sendmsg() more robust against bonding changessyzbot was able to trick llc_ui_sendmsg(), allocating an skb with noheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]Like some others, llc_ui_sendmsg() releases the socket lock beforecalling sock_alloc_send_skb().Then it acquires it again, but does not redo all the sanity checksthat were performed.This fix:- Uses LL_RESERVED_SPACE() to reserve space.- Check all conditions again after socket lock is held again.- Do not account Ethernet header for mtu limitation.[1]skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0 kernel BUG at net/core/skbuff.c:193 !Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_panic net/core/skbuff.c:189 [inline] pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 lr : skb_panic net/core/skbuff.c:189 [inline] lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203sp : ffff800096f97000x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261cex17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089Call trace: skb_panic net/core/skbuff.c:189 [inline] skb_under_panic+0x13c/0x140 net/core/skbuff.c:203 skb_push+0xf0/0x108 net/core/skbuff.c:2451 eth_header+0x44/0x1f8 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3188 [inline] llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33 llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209 llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270 llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] sock_sendmsg+0x194/0x274 net/socket.c:767 splice_to_socket+0x7cc/0xd58 fs/splice.c:881 do_splice_from fs/splice.c:933 [inline] direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142 splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088 do_splice_direct+0x20c/0x348 fs/splice.c:1194 do_sendfile+0x4bc/0xc70 fs/read_write.c:1254 __do_sys_sendfile64 fs/read_write.c:1322 [inline] __se_sys_sendfile64 fs/read_write.c:1308 [inline] __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308 __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155 el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: add sanity checks to rx zerocopyTCP rx zerocopy intent is to map pages initially allocatedfrom NIC drivers, not pages owned by a fs.This patch adds to can_map_frag() these additional checks:- Page must not be a compound one.- page->mapping must be NULL.This fixes the panic reported by ZhangPeng.syzbot was able to loopback packets built with sendfile(),mapping pages owned by an ext4 file to TCP rx zerocopy.r3 = socket$inet_tcp(0x2, 0x1, 0x0)mmap(&(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)r4 = socket$inet_tcp(0x2, 0x1, 0x0)bind$inet(r4, &(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)connect$inet(r4, &(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)r5 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)fallocate(r5, 0x0, 0x0, 0x85b8)sendfile(r4, r5, 0x0, 0x8ba0)getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23, &(0x7f00000001c0)={&(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, &(0x7f0000000440)=0x40)r6 = openat$dir(0xffffffffffffff9c, &(0x7f00000000c0)='./file0\x00', 0x181e42, 0x0)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Ensure visibility when inserting an element into tracing_mapRunning the following two commands in parallel on a multi-processorAArch64 machine can sporadically produce an unexpected warning aboutduplicate histogram entries: $ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)The warning looks as follows:[ 2911.172474] ------------[ cut here ]------------[ 2911.173111] Duplicates detected: 1[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408[ 2911.174702] Modules linked in: iscsi_ibft(E) iscsi_boot_sysfs(E) rfkill(E) af_packet(E) nls_iso8859_1(E) nls_cp437(E) vfat(E) fat(E) ena(E) tiny_power_button(E) qemu_fw_cfg(E) button(E) fuse(E) efi_pstore(E) ip_tables(E) x_tables(E) xfs(E) libcrc32c(E) aes_ce_blk(E) aes_ce_cipher(E) crct10dif_ce(E) polyval_ce(E) polyval_generic(E) ghash_ce(E) gf128mul(E) sm4_ce_gcm(E) sm4_ce_ccm(E) sm4_ce(E) sm4_ce_cipher(E) sm4(E) sm3_ce(E) sm3(E) sha3_ce(E) sha512_ce(E) sha512_arm64(E) sha2_ce(E) sha256_arm64(E) nvme(E) sha1_ce(E) nvme_core(E) nvme_auth(E) t10_pi(E) sg(E) scsi_mod(E) scsi_common(E) efivarfs(E)[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408[ 2911.185310] sp : ffff8000a1513900[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480[ 2911.194259] Call trace:[ 2911.194626] tracing_map_sort_entries+0x3e0/0x408[ 2911.195220] hist_show+0x124/0x800[ 2911.195692] seq_read_iter+0x1d4/0x4e8[ 2911.196193] seq_read+0xe8/0x138[ 2911.196638] vfs_read+0xc8/0x300[ 2911.197078] ksys_read+0x70/0x108[ 2911.197534] __arm64_sys_read+0x24/0x38[ 2911.198046] invoke_syscall+0x78/0x108[ 2911.198553] el0_svc_common.constprop.0+0xd0/0xf8[ 2911.199157] do_el0_svc+0x28/0x40[ 2911.199613] el0_svc+0x40/0x178[ 2911.200048] el0t_64_sync_handler+0x13c/0x158[ 2911.200621] el0t_64_sync+0x1a8/0x1b0[ 2911.201115] ---[ end trace 0000000000000000 ]---The problem appears to be caused by CPU reordering of writes issued from__tracing_map_insert().The check for the presence of an element with a given key in thisfunction is: val = READ_ONCE(entry->val); if (val && keys_match(key, val->key, map->key_size)) ...The write of a new entry is: elt = get_free_elt(map); memcpy(elt->key, key, map->key_size); entry->val = elt;The "memcpy(elt->key, key, map->key_size);" and "entry->val = elt;"stores may become visible in the reversed order on another CPU. Thissecond CPU might then incorrectly determine that a new key doesn't matchan already present val->key and subse---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: handle isoc Babble and Buffer Overrun events properlyxHCI 4.9 explicitly forbids assuming that the xHC has released itsownership of a multi-TRB TD when it reports an error on one of theearly TRBs. Yet the driver makes such assumption and releases the TD,allowing the remaining TRBs to be freed or overwritten by new TDs.The xHC should also report completion of the final TRB due to its IOCflag being set by us, regardless of prior errors. This event cannotbe recognized if the TD has already been freed earlier, resulting in"Transfer event TRB DMA ptr not part of current TD" error message.Fix this by reusing the logic for processing isoc Transaction Errors.This also handles hosts which fail to report the final completion.Fix transfer length reporting on Babble errors. They may be caused bydevice malfunction, no guarantee that the buffer has been filled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Implement bounds check for stream encoder creation in DCN301'stream_enc_regs' array is an array of dcn10_stream_enc_registersstructures. The array is initialized with four elements, correspondingto the four calls to stream_enc_regs() in the array initializer. Thismeans that valid indices for this array are 0, 1, 2, and 3.The error message 'stream_enc_regs' 4 <= 5 below, is indicating thatthere is an attempt to access this array with an index of 5, which isout of bounds. This could lead to undefined behaviorHere, eng_id is used as an index to access the stream_enc_regs array. Ifeng_id is 5, this would result in an out-of-bounds access on thestream_enc_regs array.Thus fixing Buffer overflow error in dcn301_stream_encoder_createreported by Smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn301/dcn301_resource.c:1011 dcn301_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26662 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix 'panel_cntl' could be null in 'dcn21_set_backlight_level()''panel_cntl' structure used to control the display panel could be null,dereferencing it could lead to a null pointer access.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn21/dcn21_hwseq.c:269 dcn21_set_backlight_level() error: we previously assumed 'panel_cntl' could be null (see line 250)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26664 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (coretemp) Fix out-of-bounds memory accessFix a bug that pdata->cpu_map[] is set before out-of-bounds check.The problem might be triggered on systems with more than 128 cores perpackage.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26669 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: flower: Fix chain template offloadWhen a qdisc is deleted from a net device the stack instructs theunderlying driver to remove its flow offload callback from theassociated filter block using the 'FLOW_BLOCK_UNBIND' command. The stackthen continues to replay the removal of the filters in the block forthis driver by iterating over the chains in the block and invoking the'reoffload' operation of the classifier being used. In turn, theclassifier in its 'reoffload' operation prepares and emits a'FLOW_CLS_DESTROY' command for each filter.However, the stack does not do the same for chain templates and theunderlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command whena qdisc is deleted. This results in a memory leak [1] which can bereproduced using [2].Fix by introducing a 'tmplt_reoffload' operation and have the stackinvoke it with the appropriate arguments as part of the replay.Implement the operation in the sole classifier that supports chaintemplates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'command based on whether a flow offload callback is being bound to afilter block or being unbound from one.As far as I can tell, the issue happens since cited commit whichreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()in __tcf_block_put(). The order cannot be reversed as the filter blockis expected to be freed after flushing all the chains.[1]unreferenced object 0xffff888107e28800 (size 2048): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff ..|......[...... 01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff ................ backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc+0x4e/0x90 [] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80 [] ___sys_sendmsg+0x13a/0x1e0 [] __sys_sendmsg+0x11c/0x1f0 [] do_syscall_64+0x40/0xe0unreferenced object 0xffff88816d2c0400 (size 1024): comm "tc", pid 1079, jiffies 4294958525 (age 3074.287s) hex dump (first 32 bytes): 40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00 @.......W.8..... 10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff ..,m......,m.... backtrace: [] __kmem_cache_alloc_node+0x1e8/0x320 [] __kmalloc_node+0x51/0x90 [] kvmalloc_node+0xa6/0x1f0 [] bucket_table_alloc.isra.0+0x83/0x460 [] rhashtable_init+0x43b/0x7c0 [] mlxsw_sp_acl_ruleset_get+0x428/0x7a0 [] mlxsw_sp_flower_tmplt_create+0x145/0x180 [] mlxsw_sp_flow_block_cb+0x1ea/0x280 [] tc_setup_cb_call+0x183/0x340 [] fl_tmplt_create+0x3da/0x4c0 [] tc_ctl_chain+0xa15/0x1170 [] rtnetlink_rcv_msg+0x3cc/0xed0 [] netlink_rcv_skb+0x170/0x440 [] netlink_unicast+0x540/0x820 [] netlink_sendmsg+0x8d8/0xda0 [] ____sys_sendmsg+0x30f/0xa80[2] # tc qdisc add dev swp1 clsact # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32 # tc qdisc del dev---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26671 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can't get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in < 30min when running it on my test VMin laptop. modprobe -r scsi_debug modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4 dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename` fio --filename=/dev/"$dev" --direct=1 --rw=randrw --bs=4k --iodepth=1 \ --runtime=100 --numjobs=40 --time_based --name=test \ --ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26673 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.- Disallow layer 4 protocol with no ports, since destination port is a mandatory attribute for this object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot triggered a warning [1] in __alloc_pages():WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)Willem fixed a similar issue in commit c0a2a1b0d631 ("ppp: limit MRU to 64K")Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)[1]: WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call trace: __alloc_pages+0x308/0x698 mm/page_alloc.c:4543 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926 __do_kmalloc_node mm/slub.c:3969 [inline] __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001 kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590 __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651 __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715 netdev_alloc_skb include/linux/skbuff.h:3235 [inline] dev_alloc_skb include/linux/skbuff.h:3248 [inline] ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline] ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341 tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390 tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37 receive_buf drivers/tty/tty_buffer.c:444 [inline] flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: atlantic: Fix DMA mapping for PTP hwts ringFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytesfor PTP HWTS ring but then generic aq_ring_free() does not take thisinto account.Create and use a specific function to free HWTS ring to fix thisissue.Trace:[ 215.351607] ------------[ cut here ]------------[ 215.351612] DMA-API: atlantic 0000:4b:00.0: device driver frees DMA memory with different size [device address=0x00000000fbdd0000] [map size=34816 bytes] [unmap size=32768 bytes][ 215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360...[ 215.581176] Call Trace:[ 215.583632] [ 215.585745] ? show_trace_log_lvl+0x1c4/0x2df[ 215.590114] ? show_trace_log_lvl+0x1c4/0x2df[ 215.594497] ? debug_dma_free_coherent+0x196/0x210[ 215.599305] ? check_unmap+0xa6f/0x2360[ 215.603147] ? __warn+0xca/0x1d0[ 215.606391] ? check_unmap+0xa6f/0x2360[ 215.610237] ? report_bug+0x1ef/0x370[ 215.613921] ? handle_bug+0x3c/0x70[ 215.617423] ? exc_invalid_op+0x14/0x50[ 215.621269] ? asm_exc_invalid_op+0x16/0x20[ 215.625480] ? check_unmap+0xa6f/0x2360[ 215.629331] ? mark_lock.part.0+0xca/0xa40[ 215.633445] debug_dma_free_coherent+0x196/0x210[ 215.638079] ? __pfx_debug_dma_free_coherent+0x10/0x10[ 215.643242] ? slab_free_freelist_hook+0x11d/0x1d0[ 215.648060] dma_free_attrs+0x6d/0x130[ 215.651834] aq_ring_free+0x193/0x290 [atlantic][ 215.656487] aq_ptp_ring_free+0x67/0x110 [atlantic]...[ 216.127540] ---[ end trace 6467e5964dd2640b ]---[ 216.132160] DMA-API: Mapped at:[ 216.132162] debug_dma_alloc_coherent+0x66/0x2f0[ 216.132165] dma_alloc_attrs+0xf5/0x1b0[ 216.132168] aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic][ 216.132193] aq_ptp_ring_alloc+0x1bb/0x540 [atlantic][ 216.132213] aq_nic_init+0x4a1/0x760 [atlantic]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: xgmac: fix handling of DPP safety error for DMA channelsCommit 56e58d6c8a56 ("net: stmmac: Implement Safety Features inXGMAC core") checks and reports safety errors, but leaves theData Path Parity Errors for each channel in DMA unhandled at all, lead toa storm of interrupt.Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential bug in end_buffer_async_writeAccording to a syzbot report, end_buffer_async_write(), which handles thecompletion of block device writes, may detect abnormal condition of thebuffer async_write flag and cause a BUG_ON failure when using nilfs2.Nilfs2 itself does not use end_buffer_async_write(). But, the async_writeflag is now used as a marker by commit 7f42ec394156 ("nilfs2: fix issuewith race condition of competition between segments for dirty blocks") asa means of resolving double list insertion of dirty blocks innilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and theresulting crash.This modification is safe as long as it is used for file data and b-treenode blocks where the page caches are independent. However, it wasirrelevant and redundant to also introduce async_write for segment summaryand super root blocks that share buffers with the backing device. Thisled to the possibility that the BUG_ON check in end_buffer_async_writewould fail as described above, if independent writebacks of the backingdevice occurred in parallel.The use of async_write for segment summary buffers has already beenremoved in a previous change.Fix this issue by removing the manipulation of the async_write flag forthe remaining super root block buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_lockedThe SEV platform device can be shutdown with a null psp_master,e.g., using DEBUG_TEST_DRIVER_REMOVE. Found using KASAN:[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)[ 137.162647] ccp 0000:23:00.1: no command queues available[ 137.170598] ccp 0000:23:00.1: sev enabled[ 137.174645] ccp 0000:23:00.1: psp enabled[ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI[ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7][ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311[ 137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180[ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c[ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216[ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e[ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0[ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66[ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28[ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8[ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000[ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0[ 137.182693] Call Trace:[ 137.182693] [ 137.182693] ? show_regs+0x6c/0x80[ 137.182693] ? __die_body+0x24/0x70[ 137.182693] ? die_addr+0x4b/0x80[ 137.182693] ? exc_general_protection+0x126/0x230[ 137.182693] ? asm_exc_general_protection+0x2b/0x30[ 137.182693] ? __sev_platform_shutdown_locked+0x51/0x180[ 137.182693] sev_firmware_shutdown.isra.0+0x1e/0x80[ 137.182693] sev_dev_destroy+0x49/0x100[ 137.182693] psp_dev_destroy+0x47/0xb0[ 137.182693] sp_destroy+0xbb/0x240[ 137.182693] sp_pci_remove+0x45/0x60[ 137.182693] pci_device_remove+0xaa/0x1d0[ 137.182693] device_remove+0xc7/0x170[ 137.182693] really_probe+0x374/0xbe0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] __driver_probe_device+0x199/0x460[ 137.182693] driver_probe_device+0x4e/0xd0[ 137.182693] __driver_attach+0x191/0x3d0[ 137.182693] ? __pfx___driver_attach+0x10/0x10[ 137.182693] bus_for_each_dev+0x100/0x190[ 137.182693] ? __pfx_bus_for_each_dev+0x10/0x10[ 137.182693] ? __kasan_check_read+0x15/0x20[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? _raw_spin_unlock+0x27/0x50[ 137.182693] driver_attach+0x41/0x60[ 137.182693] bus_add_driver+0x2a8/0x580[ 137.182693] driver_register+0x141/0x480[ 137.182693] __pci_register_driver+0x1d6/0x2a0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? esrt_sysfs_init+0x1cd/0x5d0[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] sp_pci_init+0x22/0x30[ 137.182693] sp_mod_init+0x14/0x30[ 137.182693] ? __pfx_sp_mod_init+0x10/0x10[ 137.182693] do_one_initcall+0xd1/0x470[ 137.182693] ? __pfx_do_one_initcall+0x10/0x10[ 137.182693] ? parameq+0x80/0xf0[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] ? __kmalloc+0x3b0/0x4e0[ 137.182693] ? kernel_init_freeable+0x92d/0x1050[ 137.182693] ? kasan_populate_vmalloc_pte+0x171/0x190[ 137.182693] ? srso_return_thunk+0x5/0x5f[ 137.182693] kernel_init_freeable+0xa64/0x1050[ 137.182693] ? __pfx_kernel_init+0x10/0x10[ 137.182693] kernel_init+0x24/0x160[ 137.182693] ? __switch_to_asm+0x3e/0x70[ 137.182693] ret_from_fork+0x40/0x80[ 137.182693] ? __pfx_kernel_init+0x1---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()Syzbot reported a hang issue in migrate_pages_batch() called by mbind()and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.While migrate_pages_batch() locks a folio and waits for the writeback tocomplete, the log writer thread that should bring the writeback tocompletion picks up the folio being written back innilfs_lookup_dirty_data_buffers() that it calls for subsequent logcreation and was trying to lock the folio. Thus causing a deadlock.In the first place, it is unexpected that folios/pages in the middle ofwriteback will be updated and become dirty. Nilfs2 adds a checksum toverify the validity of the log being written and uses it for recovery atmount, so data changes during writeback are suppressed. Since this isbroken, an unclean shutdown could potentially cause recovery to fail.Investigation revealed that the root cause is that the wait for writebackcompletion in nilfs_page_mkwrite() is conditional, and if the backingdevice does not require stable writes, data may be modified withoutwaiting.Fix these issues by making nilfs_page_mkwrite() wait for writeback tofinish regardless of the stable write requirement of the backing device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix race condition between netvsc_probe and netvsc_removeIn commit ac5047671758 ("hv_netvsc: Disable NAPI before closing theVMBus channel"), napi_disable was getting called for all channels,including all subchannels without confirming if they are enabled or not.This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()has finished running but nvdev->subchan_work has not started yet.netvsc_subchan_work() -> rndis_set_subchannel() has not created thesub-channels and because of that netvsc_sc_open() is not running.netvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for whichnetvsc_subchan_work did not run.netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPIcannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear theNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does theopposite.Now during netvsc_device_remove(), when napi_disable is called for thosesubchannels, napi_disable gets stuck on infinite msleep.This fix addresses this problem by ensuring that napi_disable() is notgetting called for non-enabled NAPI struct.But netif_napi_del() is still necessary for these non-enabled NAPI structfor cleanup purpose.Call trace:[ 654.559417] task:modprobe state:D stack: 0 pid: 2321 ppid: 1091 flags:0x00004002[ 654.568030] Call Trace:[ 654.571221] [ 654.573790] __schedule+0x2d6/0x960[ 654.577733] schedule+0x69/0xf0[ 654.581214] schedule_timeout+0x87/0x140[ 654.585463] ? __bpf_trace_tick_stop+0x20/0x20[ 654.590291] msleep+0x2d/0x40[ 654.593625] napi_disable+0x2b/0x80[ 654.597437] netvsc_device_remove+0x8a/0x1f0 [hv_netvsc][ 654.603935] rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc][ 654.611101] ? do_wait_intr+0xb0/0xb0[ 654.615753] netvsc_remove+0x7c/0x120 [hv_netvsc][ 654.621675] vmbus_remove+0x27/0x40 [hv_vmbus]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRCRecently, we encounter kernel crash in function rm3100_common_probecaused by out of bound access of array rm3100_samp_rates (because ofunderlying hardware failures). Add boundary check to prevent out ofbound access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()Syzkaller reported [1] hitting a warning after failing to allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294...Call Trace: hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700 expire_timers kernel/time/timer.c:1751 [inline] __run_timers+0x764/0xb20 kernel/time/timer.c:2022 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035 __do_softirq+0x21a/0x8de kernel/softirq.c:553 invoke_softirq kernel/softirq.c:427 [inline] __irq_exit_rcu kernel/softirq.c:632 [inline] irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649...This issue is also found in older kernels (at least up to 5.10).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid-of: fix NULL-deref on failed power upA while back the I2C HID implementation was split in an ACPI and OFpart, but the new OF driver never initialises the client pointer whichis dereferenced on power-up failures.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt, dm-verity: disable taskletsTasklets have an inherent problem with memory corruption. The functiontasklet_action_common calls tasklet_trylock, then it calls the taskletcallback and then it calls tasklet_unlock. If the tasklet callback freesthe structure that contains the tasklet or if it calls some code that mayfree it, tasklet_unlock will write into free memory.The commits 8e14f610159d and d9a02e016aaf try to fix it for dm-crypt, butit is not a sufficient fix and the data corruption can still happen [1].There is no fix for dm-verity and dm-verity will write into free memorywith every tasklet-processed bio.There will be atomic workqueues implemented in the kernel 6.9 [2]. Theywill have better interface and they will not suffer from the memorycorruption problem.But we need something that stops the memory corruption now and that can bebackported to the stable kernels. So, I'm proposing this commit thatdisables tasklets in both dm-crypt and dm-verity. This commit doesn'tremove the tasklet support, because the tasklet code will be reused whenatomic workqueues will be implemented.[1] https://lore.kernel.org/all/d390d7ee-f142-44d3-822a-87949e14608b@suse.de/T/[2] https://lore.kernel.org/lkml/20240130091300.2968534-1-tj@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26742 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: smartpqi: Fix disable_managed_interruptsCorrect blk-mq registration issue with module parameterdisable_managed_interrupts enabled.When we turn off the default PCI_IRQ_AFFINITY flag, the driver needs toregister with blk-mq using blk_mq_map_queues(). The driver is currentlycalling blk_mq_pci_map_queues() which results in a stack trace and possiblyundefined behavior.Stack Trace:[ 7.860089] scsi host2: smartpqi[ 7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0[ 7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse[ 7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1[ 7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022[ 7.963026] Workqueue: events work_for_cpu_fn[ 7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0[ 7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54[ 7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216[ 7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010[ 7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310[ 7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00[ 7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000[ 7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8[ 7.978290] FS: 0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000[ 7.978292] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0[ 8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 8.172818] PKRU: 55555554[ 8.172819] Call Trace:[ 8.172823] blk_mq_alloc_tag_set+0x12e/0x310[ 8.264339] scsi_add_host_with_dma.cold.9+0x30/0x245[ 8.279302] pqi_ctrl_init+0xacf/0xc8e [smartpqi][ 8.294085] ? pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.309015] pqi_pci_probe+0x480/0x4c8 [smartpqi][ 8.323286] local_pci_probe+0x42/0x80[ 8.337855] work_for_cpu_fn+0x16/0x20[ 8.351193] process_one_work+0x1a7/0x360[ 8.364462] ? create_worker+0x1a0/0x1a0[ 8.379252] worker_thread+0x1ce/0x390[ 8.392623] ? create_worker+0x1a0/0x1a0[ 8.406295] kthread+0x10a/0x120[ 8.418428] ? set_kthread_struct+0x50/0x50[ 8.431532] ret_from_fork+0x1f/0x40[ 8.444137] ---[ end trace 1bf0173d39354506 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call Trace: parse_one+0x18c/0x1d0 parse_args+0xe1/0x230 load_module+0x8de/0xa60 init_module_from_file+0x8b/0xd0 idempotent_init_module+0x181/0x240 __x64_sys_finit_module+0x5a/0xb0 do_syscall_64+0x5f/0xe0 entry_SYSCALL_64_after_hwframe+0x6e/0x76

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: fix memory double free when handle zero packet829 if (request->complete) {830 spin_unlock(&priv_dev->lock);831 usb_gadget_giveback_request(&priv_ep->endpoint,832 request);833 spin_lock(&priv_dev->lock);834 }835836 if (request->buf == priv_dev->zlp_buf)837 cdns3_gadget_ep_free_request(&priv_ep->endpoint, request);Driver append an additional zero packet request when queue a packet, whichlength mod max packet size is 0. When transfer complete, run to line 831,usb_gadget_giveback_request() will free this requestion. 836 condition istrue, so cdns3_gadget_ep_free_request() free this request again.Log:[ 1920.140696][ T150] BUG: KFENCE: use-after-free read in cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.140696][ T150][ 1920.151837][ T150] Use-after-free read at 0x000000003d1cd10b (in kfence-#36):[ 1920.159082][ T150] cdns3_gadget_giveback+0x134/0x2c0 [cdns3][ 1920.164988][ T150] cdns3_transfer_completed+0x438/0x5f8 [cdns3]Add check at line 829, skip call usb_gadget_giveback_request() if it isadditional zero length packet request. Needn't callusb_gadget_giveback_request() because it is allocated in this driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26754 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()The gtp_net_ops pernet operations structure for the subsystem must beregistered before registering the generic netlink family.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:general protection fault, probably for non-canonical address0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86 df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74RSP: 0018:ffff888014107220 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000FS: 00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? show_regs+0x90/0xa0 ? die_addr+0x50/0xd0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp] ? __alloc_skb+0x1dd/0x350 ? __pfx___alloc_skb+0x10/0x10 genl_dumpit+0x11d/0x230 netlink_dump+0x5b9/0xce0 ? lockdep_hardirqs_on_prepare+0x253/0x430 ? __pfx_netlink_dump+0x10/0x10 ? kasan_save_track+0x10/0x40 ? __kasan_kmalloc+0x9b/0xa0 ? genl_start+0x675/0x970 __netlink_dump_start+0x6fc/0x9f0 genl_family_rcv_msg_dumpit+0x1bb/0x2d0 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10 ? genl_op_from_small+0x2a/0x440 ? cap_capable+0x1d0/0x240 ? __pfx_genl_start+0x10/0x10 ? __pfx_genl_dumpit+0x10/0x10 ? __pfx_genl_done+0x10/0x10 ? security_capable+0x9d/0xe0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-crypt: don't modify the data when using authenticated encryptionIt was said that authenticated encryption could produce invalid tag whenthe data that is being encrypted is modified [1]. So, fix this problem bycopying the data into the clone bio first and then encrypt them inside theclone bio.This may reduce performance, but it is needed to prevent the user fromcorrupting the device by writing data with O_DIRECT and modifying them atthe same time.[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: edma: Add some null pointer checks to the edma_probedevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()Places the logic for checking if the group's block bitmap is corrupt underthe protection of the group lock to avoid allocating blocks from the groupwith a corrupted block bitmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26775 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aoe: avoid potential deadlock at set_capacityMove set_capacity() outside of the section procected by (&d->lock).To avoid possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ----[1] lock(&bdev->bd_size_lock); local_irq_disable(); [2] lock(&d->lock); [3] lock(&bdev->bd_size_lock); [4] lock(&d->lock); *** DEADLOCK ***Where [1](&bdev->bd_size_lock) hold by zram_add()->set_capacity().[2]lock(&d->lock) hold by aoeblk_gdalloc(). And aoeblk_gdalloc()is trying to acquire [3](&bdev->bd_size_lock) at set_capacity() call.In this situation an attempt to acquire [4]lock(&d->lock) fromaoecmd_cfg_rsp() will lead to deadlock.So the simplest solution is breaking lock dependency[2](&d->lock) -> [3](&bdev->bd_size_lock) by moving set_capacity()outside.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detectedReturn IRQ_NONE from the interrupt handler when no interrupt wasdetected. Because an empty interrupt will cause a null pointer error: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: complete+0x54/0x100 hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx] __handle_irq_event_percpu+0x64/0x1e0 handle_irq_event+0x7c/0x1cc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: sis: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn't check the value of pixclock,it may cause divide-by-zero error.In sisfb_check_var(), var->pixclock is used as a divisor to caculatedrate before it is checked against zero. Fix this by checking itat the beginning.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix race condition on enabling fast-xmitfast-xmit must only be enabled after the sta has been uploaded to the driver,otherwise it could end up passing the not-yet-uploaded sta via drv_tx callsto the driver, leading to potential crashes because of uninitialized drv_privdata.Add a missing sta->uploaded check and re-check fast xmit after inserting a sta.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: mmci: stm32: fix DMA API overlapping mappings warningTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,overlapping mappings aren't supportedWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568add_dma_entry+0x234/0x2f4Modules linked in:CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)Workqueue: events_freezable mmc_rescanCall trace:add_dma_entry+0x234/0x2f4debug_dma_map_sg+0x198/0x350__dma_map_sg_attrs+0xa0/0x110dma_map_sg_attrs+0x10/0x2csdmmc_idma_prep_data+0x80/0xc0mmci_prep_data+0x38/0x84mmci_start_data+0x108/0x2dcmmci_request+0xe4/0x190__mmc_start_request+0x68/0x140mmc_start_request+0x94/0xc0mmc_wait_for_req+0x70/0x100mmc_send_tuning+0x108/0x1acsdmmc_execute_tuning+0x14c/0x210mmc_execute_tuning+0x48/0xecmmc_sd_init_uhs_card.part.0+0x208/0x464mmc_sd_init_card+0x318/0x89cmmc_attach_sd+0xe4/0x180mmc_rescan+0x244/0x320DMA API debug brings to light leaking dma-mappings as dma_map_sg anddma_unmap_sg are not correctly balanced.If an error occurs in mmci_cmd_irq function, only mmci_dma_errorfunction is called and as this API is not managed on stm32 variant,dma_unmap_sg is never called in this error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26788 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: init irq after reg initializationInitialize the qDMA irqs after the registers are configured so thatinterrupts that may have been pending from a primary kernel don't getprocessed by the irq handler before it is ready to and cause panic withthe following trace: Call trace: fsl_qdma_queue_handler+0xf8/0x3e8 __handle_irq_event_percpu+0x78/0x2b0 handle_irq_event_percpu+0x1c/0x68 handle_irq_event+0x44/0x78 handle_fasteoi_irq+0xc8/0x178 generic_handle_irq+0x24/0x38 __handle_domain_irq+0x90/0x100 gic_handle_irq+0x5c/0xb8 el1_irq+0xb8/0x180 _raw_spin_unlock_irqrestore+0x14/0x40 __setup_irq+0x4bc/0x798 request_threaded_irq+0xd8/0x190 devm_request_threaded_irq+0x74/0xe8 fsl_qdma_probe+0x4d4/0xca8 platform_drv_probe+0x50/0xa0 really_probe+0xe0/0x3f8 driver_probe_device+0x64/0x130 device_driver_attach+0x6c/0x78 __driver_attach+0xbc/0x158 bus_for_each_dev+0x5c/0x98 driver_attach+0x20/0x28 bus_add_driver+0x158/0x220 driver_register+0x60/0x110 __platform_driver_register+0x44/0x50 fsl_qdma_driver_init+0x18/0x20 do_one_initcall+0x48/0x258 kernel_init_freeable+0x1a4/0x23c kernel_init+0x10/0xf8 ret_from_fork+0x10/0x18

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26790 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: fix SoC may hang on 16 byte unaligned readThere is chip (ls1028a) errata:The SoC may hang on 16 byte unaligned read transactions by QDMA.Unaligned read transactions initiated by QDMA may stall in the NOC(Network On-Chip), causing a deadlock condition. Stalled transactions willtrigger completion timeouts in PCIe controller.Workaround:Enable prefetch by setting the source descriptor prefetchable bit( SD[PF] = 1 ).Implement this workaround.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: dev-replace: properly validate device namesThere's a syzbot report that device name buffers passed to devicereplace are not properly checked for string termination which could leadto a read out of bounds in getname_kernel().Add a helper that validates both source and target device name buffers.For devid as the source initialize the buffer to empty string in casesomething tries to read it later.This was originally analyzed and fixed in a different way by Edward AdamDavis (see links).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26793 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix use-after-free and null-ptr-deref in gtp_newlink()The gtp_link_ops operations structure for the subsystem must beregistered after registering the gtp_net_ops pernet operations structure.Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:[ 1010.702740] gtp: GTP module unloaded[ 1010.715877] general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] SMP KASAN NOPTI[ 1010.715888] KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f][ 1010.715895] CPU: 1 PID: 128616 Comm: a.out Not tainted 6.8.0-rc6-std-def-alt1 #1[ 1010.715899] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014[ 1010.715908] RIP: 0010:gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.715915] Code: 80 3c 02 00 0f 85 41 04 00 00 48 8b bb d8 05 00 00 e8 ed f6 ff ff 48 89 c2 48 89 c5 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 0f 85 4f 04 00 00 4c 89 e2 4c 8b 6d 00 48 b8 00 00 00[ 1010.715920] RSP: 0018:ffff888020fbf180 EFLAGS: 00010203[ 1010.715929] RAX: dffffc0000000000 RBX: ffff88800399c000 RCX: 0000000000000000[ 1010.715933] RDX: 0000000000000001 RSI: ffffffff84805280 RDI: 0000000000000282[ 1010.715938] RBP: 000000000000000d R08: 0000000000000001 R09: 0000000000000000[ 1010.715942] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88800399cc80[ 1010.715947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000400[ 1010.715953] FS: 00007fd1509ab5c0(0000) GS:ffff88805b300000(0000) knlGS:0000000000000000[ 1010.715958] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1010.715962] CR2: 0000000000000000 CR3: 000000001c07a000 CR4: 0000000000750ee0[ 1010.715968] PKRU: 55555554[ 1010.715972] Call Trace:[ 1010.715985] ? __die_body.cold+0x1a/0x1f[ 1010.715995] ? die_addr+0x43/0x70[ 1010.716002] ? exc_general_protection+0x199/0x2f0[ 1010.716016] ? asm_exc_general_protection+0x1e/0x30[ 1010.716026] ? gtp_newlink+0x4d7/0x9c0 [gtp][ 1010.716034] ? gtp_net_exit+0x150/0x150 [gtp][ 1010.716042] __rtnl_newlink+0x1063/0x1700[ 1010.716051] ? rtnl_setlink+0x3c0/0x3c0[ 1010.716063] ? is_bpf_text_address+0xc0/0x1f0[ 1010.716070] ? kernel_text_address.part.0+0xbb/0xd0[ 1010.716076] ? __kernel_text_address+0x56/0xa0[ 1010.716084] ? unwind_get_return_address+0x5a/0xa0[ 1010.716091] ? create_prof_cpu_mask+0x30/0x30[ 1010.716098] ? arch_stack_walk+0x9e/0xf0[ 1010.716106] ? stack_trace_save+0x91/0xd0[ 1010.716113] ? stack_trace_consume_entry+0x170/0x170[ 1010.716121] ? __lock_acquire+0x15c5/0x5380[ 1010.716139] ? mark_held_locks+0x9e/0xe0[ 1010.716148] ? kmem_cache_alloc_trace+0x35f/0x3c0[ 1010.716155] ? __rtnl_newlink+0x1700/0x1700[ 1010.716160] rtnl_newlink+0x69/0xa0[ 1010.716166] rtnetlink_rcv_msg+0x43b/0xc50[ 1010.716172] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716179] ? lock_acquire+0x1fe/0x560[ 1010.716188] ? netlink_deliver_tap+0x12f/0xd50[ 1010.716196] netlink_rcv_skb+0x14d/0x440[ 1010.716202] ? rtnl_fdb_dump+0x9f0/0x9f0[ 1010.716208] ? netlink_ack+0xab0/0xab0[ 1010.716213] ? netlink_deliver_tap+0x202/0xd50[ 1010.716220] ? netlink_deliver_tap+0x218/0xd50[ 1010.716226] ? __virt_addr_valid+0x30b/0x590[ 1010.716233] netlink_unicast+0x54b/0x800[ 1010.716240] ? netlink_attachskb+0x870/0x870[ 1010.716248] ? __check_object_size+0x2de/0x3b0[ 1010.716254] netlink_sendmsg+0x938/0xe40[ 1010.716261] ? netlink_unicast+0x800/0x800[ 1010.716269] ? __import_iovec+0x292/0x510[ 1010.716276] ? netlink_unicast+0x800/0x800[ 1010.716284] __sock_sendmsg+0x159/0x190[ 1010.716290] ____sys_sendmsg+0x712/0x880[ 1010.716297] ? sock_write_iter+0x3d0/0x3d0[ 1010.716304] ? __ia32_sys_recvmmsg+0x270/0x270[ 1010.716309] ? lock_acquire+0x1fe/0x560[ 1010.716315] ? drain_array_locked+0x90/0x90[ 1010.716324] ___sys_sendmsg+0xf8/0x170[ 1010.716331] ? sendmsg_copy_msghdr+0x170/0x170[ 1010.716337] ? lockdep_init_map---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: always restore the old font data in fbcon_do_set_font()Commit a5a923038d70 (fbdev: fbcon: Properly revert changes whenvc_resize() failed) started restoring old font data upon failure (ofvc_resize()). But it performs so only for user fonts. It means that the"system"/internal fonts are not restored at all. So in result, the veryfirst call to fbcon_do_set_font() performs no restore at all uponfailing vc_resize().This can be reproduced by Syzkaller to crash the system on the nextinvocation of font_get(). It's rather hard to hit the allocation failurein vc_resize() on the first font_set(), but not impossible. Esp. iffault injection is used to aid the execution/failure. It wasdemonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: con_font_get drivers/tty/vt/vt.c:4558 [inline] con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline] vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752 tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803 vfs_ioctl fs/ioctl.c:51 [inline] ...So restore the font data in any case, not only for user fonts. Note thelater 'if' is now protected by 'old_userfont' and not 'old_data' as thelatter is always set now. (And it is supposed to be non-NULL. Otherwisewe would see the bug above again.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here's the call trace observed on a ChromeOS device with Intel AX201: queue_work_on+0x3e/0x6c __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth ] ? init_wait_entry+0x31/0x31 __hci_cmd_sync+0x16/0x20 [bluetooth ] hci_error_reset+0x4f/0xa4 [bluetooth ] process_one_work+0x1d8/0x33f worker_thread+0x21b/0x373 kthread+0x13a/0x152 ? pr_cont_work+0x54/0x54 ? kthread_blkcg+0x31/0x31 ret_from_fork+0x1f/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stmmac: Clear variable when destroying workqueueCurrently when suspending driver and stopping workqueue it is checked whetherworkqueue is not NULL and if so, it is destroyed.Function destroy_workqueue() does drain queue and does clear variable, butit does not set workqueue variable to NULL. This can cause kernel/modulepanic if code attempts to clear workqueue that was not initialized.This scenario is possible when resuming suspended driver in stmmac_resume(),because there is no handling for failed stmmac_hw_setup(),which can fail and return if DMA engine has failed to initialize,and workqueue is initialized after DMA engine.Should DMA engine fail to initialize, resume will proceed normally,but interface won't work and TX queue will eventually timeout,causing 'Reset adapter' error.This then does destroy workqueue during reset process.And since workqueue is initialized after DMA engine and can be skipped,it will cause kernel/module panic.To secure against this possible crash, set workqueue variable to NULL whendestroying workqueue.Log/backtrace from crash goes as follows:[88.031977]------------[ cut here ]------------[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398 [88.032251]---[ end trace e70de432e4d5c2c0 ]---[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.[88.036359]------------[ cut here ]------------[88.036519]Call trace:[88.036523] flush_workqueue+0x3e4/0x430[88.036528] drain_workqueue+0xc4/0x160[88.036533] destroy_workqueue+0x40/0x270[88.036537] stmmac_fpe_stop_wq+0x4c/0x70[88.036541] stmmac_release+0x278/0x280[88.036546] __dev_close_many+0xcc/0x158[88.036551] dev_close_many+0xbc/0x190[88.036555] dev_close.part.0+0x70/0xc0[88.036560] dev_close+0x24/0x30[88.036564] stmmac_service_task+0x110/0x140[88.036569] process_one_work+0x1d8/0x4a0[88.036573] worker_thread+0x54/0x408[88.036578] kthread+0x164/0x170[88.036583] ret_from_fork+0x10/0x20[88.036588]---[ end trace e70de432e4d5c2c1 ]---[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: prevent perpetual headroom growthsyzkaller triggered following kasan splat:BUG: KASAN: use-after-free in __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170Read of size 1 at addr ffff88812fb4000e by task syz-executor183/5191[..] kasan_report+0xda/0x110 mm/kasan/report.c:588 __skb_flow_dissect+0x19d1/0x7a50 net/core/flow_dissector.c:1170 skb_flow_dissect_flow_keys include/linux/skbuff.h:1514 [inline] ___skb_get_hash net/core/flow_dissector.c:1791 [inline] __skb_get_hash+0xc7/0x540 net/core/flow_dissector.c:1856 skb_get_hash include/linux/skbuff.h:1556 [inline] ip_tunnel_xmit+0x1855/0x33c0 net/ipv4/ip_tunnel.c:748 ipip_tunnel_xmit+0x3cc/0x4e0 net/ipv4/ipip.c:308 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] neigh_connected_output+0x42c/0x5d0 net/core/neighbour.c:1592 ... ip_finish_output2+0x833/0x2550 net/ipv4/ip_output.c:235 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 .. iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ip_tunnel_xmit+0x1dbc/0x33c0 net/ipv4/ip_tunnel.c:831 ipgre_xmit+0x4a1/0x980 net/ipv4/ip_gre.c:665 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3564 ...The splat occurs because skb->data points past skb->head allocated area.This is because neigh layer does: __skb_pull(skb, skb_network_offset(skb));... but skb_network_offset() returns a negative offset and __skb_pull()arg is unsigned. IOW, we skb->data gets "adjusted" by a huge value.The negative value is returned because skb->head and skb->data distance ismore than 64k and skb->network_header (u16) has wrapped around.The bug is in the ip_tunnel infrastructure, which can causedev->needed_headroom to increment ad infinitum.The syzkaller reproducer consists of packets getting routed via a gretunnel, and route of gre encapsulated packets pointing at another (ipip)tunnel. The ipip encapsulation finds gre0 as next output device.This results in the following pattern:1). First packet is to be sent out via gre0.Route lookup found an output device, ipip0.2).ip_tunnel_xmit for gre0 bumps gre0->needed_headroom based on the futureoutput device, rt.dev->needed_headroom (ipip0).3).ip output / start_xmit moves skb on to ipip0. which runs the samecode path again (xmit recursion).4).Routing step for the post-gre0-encap packet finds gre0 as output deviceto use for ipip0 encapsulated packet.tunl0->needed_headroom is then incremented based on the (already bumped)gre0 device headroom.This repeats for every future packet:gre0->needed_headroom gets inflated because previous packets' ipip0 stepincremented rt->dev (gre0) headroom, and ipip0 incremented because gre0needed_headroom was increased.For each subsequent packet, gre/ipip0->needed_headroom grows untilpost-expand-head reallocations result in a skb->head/data distance ofmore than 64k.Once that happens, skb->network_header (u16) wraps around whenpskb_expand_head tries to make sure that skb_network_offset() is unchangedafter the headroom expansion/reallocation.After this skb_network_offset(skb) returns a different (and negative)result post headroom expansion.The next trip to neigh layer (or anything else that would __skb_pull thenetwork header) makes skb->data point to a memory location outsideskb->head area.v2: Cap the needed_headroom update to an arbitarily chosen upperlimit toprevent perpetual increase instead of dropping the headroom incrementcompletely.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix kernel-infoleak-after-free in __skb_datagram_itersyzbot reported the following uninit-value access issue [1]:netlink_to_full_skb() creates a new `skb` and puts the `skb->data`passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The datasize is specified as `len` and passed to skb_put_data(). This `len`is based on `skb->end` that is not data offset but buffer offset. The`skb->end` contains data and tailroom. Since the tailroom is notinitialized when the new `skb` created, KMSAN detects uninitializedmemory area when copying the data.This patch resolved this issue by correct the len from `skb->end` to`skb->len`, which is the actual data offset.BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186 copy_to_iter include/linux/uio.h:197 [inline] simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline] packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482 sock_recvmsg_nosec net/socket.c:1044 [inline] sock_recvmsg net/socket.c:1066 [inline] sock_read_iter+0x467/0x580 net/socket.c:1136 call_read_iter include/linux/fs.h:2014 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x8f6/0xe00 fs/read_write.c:470 ksys_read+0x20f/0x4c0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x93/0xd0 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was stored to memory at: skb_put_data include/linux/skbuff.h:2622 [inline] netlink_to_full_skb net/netlink/af_netlink.c:181 [inline] __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline] __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline] netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline] netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline] netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: free_pages_prepare mm/page_alloc.c:1087 [inline] free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533 release_pages+0x23d3/0x2410 mm/swap.c:1042 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316 tlb_batch_pages---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Both cadence-quadspi ->runtime_suspend() and ->runtime_resume()implementations start with: struct cqspi_st *cqspi = dev_get_drvdata(dev); struct spi_controller *host = dev_get_drvdata(dev);This obviously cannot be correct, unless "struct cqspi_st" is thefirst member of " struct spi_controller", or the other way around, butit is not the case. "struct spi_controller" is allocated bydevm_spi_alloc_host(), which allocates an extra amount of memory forprivate data, used to store "struct cqspi_st".The ->probe() function of the cadence-quadspi driver then sets thedevice drvdata to store the address of the "struct cqspi_st"structure. Therefore: struct cqspi_st *cqspi = dev_get_drvdata(dev);is correct, but: struct spi_controller *host = dev_get_drvdata(dev);is not, as it makes "host" point not to a "struct spi_controller" butto the same "struct cqspi_st" structure as above.This obviously leads to bad things (memory corruption, kernel crashes)directly during ->probe(), as ->probe() enables the device using PMruntime, leading the ->runtime_resume() hook being called, which inturns calls spi_controller_resume() with the wrong pointer.This has at least been reported [0] to cause a kernel crash, but theexact behavior will depend on the memory contents.[0] https://lore.kernel.org/all/20240226121803.5a7r5wkpbbowcxgx@dhruva/This issue potentially affects all platforms that are currently usingthe cadence-quadspi driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: set correct id, uid and cruid for multiuser automountsWhen uid, gid and cruid are not specified, we need to dynamicallyset them into the filesystem context used for automounting otherwisethey'll end up reusing the values from the parent mount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: free rx_data_reassembly skb on NCI device cleanuprx_data_reassembly skb is stored during NCI data exchange for processingfragmented packets. It is dropped only when the last fragment is processedor when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.However, the NCI device may be deallocated before that which leads to skbleak.As by design the rx_data_reassembly skb is bound to the NCI device andnothing prevents the device to be freed before the skb is processed insome way and cleaned, free it on the NCI device cleanup.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: ir_toy: fix a memleak in irtoy_txWhen irtoy_command fails, buf should be freed since it is allocated byirtoy_tx, or there is a memleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not allow untrusted VF to remove administratively set MACCurrently when PF administratively sets VF's MAC address and the VFis put down (VF tries to delete all MACs) then the MAC is removedfrom MAC filters and primary VF MAC is zeroed.Do not allow untrusted VF to remove primary MAC when it was setadministratively by PF.Reproducer:1) Create VF2) Set VF interface up3) Administratively set the VF's MAC4) Put VF interface down[root@host ~]# echo 1 > /sys/class/net/enp2s0f0/device/sriov_numvfs[root@host ~]# ip link set enp2s0f0v0 up[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether fe:6c:b5:da:c7:7d brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off[root@host ~]# ip link set enp2s0f0v0 down[root@host ~]# ip link show enp2s0f023: enp2s0f0: mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff vf 0 link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff, spoof checking on, link-state auto, trust off

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak in dm_sw_fini()After destroying dmub_srv, the memory associated with it isnot freed, causing a memory leak:unreferenced object 0xffff896302b45800 (size 1024): comm "(udev-worker)", pid 222, jiffies 4294894636 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 6265fd77): [] kmalloc_trace+0x29d/0x340 [] dm_dmub_sw_init+0xb4/0x450 [amdgpu] [] dm_sw_init+0x15/0x2b0 [amdgpu] [] amdgpu_device_init+0x1417/0x24e0 [amdgpu] [] amdgpu_driver_load_kms+0x15/0x190 [amdgpu] [] amdgpu_pci_probe+0x187/0x4e0 [amdgpu] [] local_pci_probe+0x3e/0x90 [] pci_device_probe+0xc3/0x230 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] do_one_initcall+0x41/0x300Fix this by freeing dmub_srv after destroying it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26838 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix KASAN issue with taskletKASAN testing revealed the following issue assocated with freeing an IRQ.[50006.466686] Call Trace:[50006.466691] [50006.489538] dump_stack+0x5c/0x80[50006.493475] print_address_description.constprop.6+0x1a/0x150[50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.511644] kasan_report.cold.11+0x7f/0x118[50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma][50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma][50006.528232] irdma_process_ceq+0xb2/0x400 [irdma][50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma][50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma][50006.545306] tasklet_action_common.isra.14+0x148/0x2c0[50006.551096] __do_softirq+0x1d0/0xaf8[50006.555396] irq_exit_rcu+0x219/0x260[50006.559670] irq_exit+0xa/0x20[50006.563320] smp_apic_timer_interrupt+0x1bf/0x690[50006.568645] apic_timer_interrupt+0xf/0x20[50006.573341] The issue is that a tasklet could be pending on another core racingthe delete of the irq.Fix by insuring any scheduled tasklet is killed after deleting theirq.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: runtime: Fix potential overflow of soft-reserved region sizemd_size will have been narrowed if we have >= 4GB worth of pages in asoft-reserved region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: Add protection for bmp length out of rangeUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shiftsthat are out of bounds for their data type.vmlinux get_bitmap(b=75) + 712vmlinux decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956vmlinux decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216vmlinux decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812vmlinux decode_choice(base=0xFFFFFFD008037280, level=0) + 1216vmlinux DecodeRasMessage() + 304vmlinux ras_help() + 684vmlinux nf_confirm() + 188Due to abnormal data in skb->data, the extension bitmap lengthexceeds 32 when decoding ras message then uses the length to makea shift operation. It will change into negative after several loop.UBSAN load could detect a negative shift as an undefined behaviourand reports exception.So we add the protection to avoid the length exceeding 32. Or elseit will return out of range error and stop decoding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igc: avoid returning frame twice in XDP_REDIRECTWhen a frame can not be transmitted in XDP_REDIRECT(e.g. due to a full queue), it is necessary to freeit by calling xdp_return_frame_rx_napi.However, this is the responsibility of the caller ofthe ndo_xdp_xmit (see for example bq_xmit_all inkernel/bpf/devmap.c) and thus calling it insideigc_xdp_xmit (which is the ndo_xdp_xmit of the igcdriver) as well will lead to memory corruption.In fact, bq_xmit_all expects that it can return allframes after the last successfully transmitted one.Therefore, break for the first not transmitted frame,but do not call xdp_return_frame_rx_napi in igc_xdp_xmit.This is equally implemented in other Intel driverssuch as the igb.There are two alternatives to this that were rejected:1. Return num_frames as all the frames would have been transmitted and release them inside igc_xdp_xmit. While it might work technically, it is not what the return value is meant to represent (i.e. the number of SUCCESSFULLY transmitted packets).2. Rework kernel/bpf/devmap.c and all drivers to support non-consecutively dropped packets. Besides being complex, it likely has a negative performance impact without a significant gain since it is anyway unlikely that the next frame can be transmitted if the previous one was dropped.The memory corruption can be reproduced withthe following script which leads to a kernel panicafter a few seconds. It basically generates moretraffic than a i225 NIC can transmit and pushes itvia XDP_REDIRECT from a virtual interface to thephysical interface where frames get dropped. #!/bin/bash INTERFACE=enp4s0 INTERFACE_IDX=`cat /sys/class/net/$INTERFACE/ifindex` sudo ip link add dev veth1 type veth peer name veth2 sudo ip link set up $INTERFACE sudo ip link set up veth1 sudo ip link set up veth2 cat << EOF > redirect.bpf.c SEC("prog") int redirect(struct xdp_md *ctx) { return bpf_redirect($INTERFACE_IDX, 0); } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c redirect.bpf.c -o redirect.bpf.o sudo ip link set veth2 xdp obj redirect.bpf.o cat << EOF > pass.bpf.c SEC("prog") int pass(struct xdp_md *ctx) { return XDP_PASS; } char _license[] SEC("license") = "GPL"; EOF clang -O2 -g -Wall -target bpf -c pass.bpf.c -o pass.bpf.o sudo ip link set $INTERFACE xdp obj pass.bpf.o cat << EOF > trafgen.cfg { /* Ethernet Header */ 0xe8, 0x6a, 0x64, 0x41, 0xbf, 0x46, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, const16(ETH_P_IP), /* IPv4 Header */ 0b01000101, 0, # IPv4 version, IHL, TOS const16(1028), # IPv4 total length (UDP length + 20 bytes (IP header)) const16(2), # IPv4 ident 0b01000000, 0, # IPv4 flags, fragmentation off 64, # IPv4 TTL 17, # Protocol UDP csumip(14, 33), # IPv4 checksum /* UDP Header */ 10, 0, 1, 1, # IP Src - adapt as needed 10, 0, 1, 2, # IP Dest - adapt as needed const16(6666), # UDP Src Port const16(6666), # UDP Dest Port const16(1008), # UDP length (UDP header 8 bytes + payload length) csumudp(14, 34), # UDP checksum /* Payload */ fill('W', 1000), } EOF sudo trafgen -i trafgen.cfg -b3000MB -o veth1 --cpp

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()The function ice_bridge_setlink() may encounter a NULL pointer dereferenceif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequentlyin nla_for_each_nested(). To address this issue, add a check to ensure thatbr_spec is not NULL before proceeding with the nested attribute iteration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sparx5: Fix use after free inside sparx5_del_mact_entryBased on the static analyzis of the code it looks like when an entryfrom the MAC table was removed, the entry was still used after beingfreed. More precise the vid of the mac_entry was used after callingdevm_kfree on the mac_entry.The fix consists in first using the vid of the mac_entry to delete theentry from the HW and after that to free it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: make sure to pull inner header in geneve_rx()syzbot triggered a bug in geneve_rx() [1]Issue is similar to the one I fixed in commit 8d975c15c0cd("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.[1]BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline] BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] geneve_rx drivers/net/geneve.c:279 [inline] geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391 udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346 __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422 udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 process_backlog+0x480/0x8b0 net/core/dev.c:5976 __napi_poll+0xe3/0x980 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [inline] net_rx_action+0x8b8/0x1870 net/core/dev.c:6778 __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553 do_softirq+0x9a/0xf0 kernel/softirq.c:454 __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline] __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x352/0x790 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1296 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/bnx2x: Prevent access to a freed page in page_poolFix race condition leading to system crash during EEH error handlingDuring EEH error recovery, the bnx2x driver's transmit timeout logiccould cause a race condition when handling reset tasks. Thebnx2x_tx_timeout() schedules reset tasks via bnx2x_sp_rtnl_task(),which ultimately leads to bnx2x_nic_unload(). In bnx2x_nic_unload()SGEs are freed using bnx2x_free_rx_sge_range(). However, this couldoverlap with the EEH driver's attempt to reset the device usingbnx2x_io_slot_reset(), which also tries to free SGEs. This racecondition can result in system crashes due to accessing freed memorylocations in bnx2x_free_rx_sge()799 static inline void bnx2x_free_rx_sge(struct bnx2x *bp,800 struct bnx2x_fastpath *fp, u16 index)801 {802 struct sw_rx_page *sw_buf = &fp->rx_page_ring[index];803 struct page *page = sw_buf->page;....where sw_buf was set to NULL after the call to dma_unmap_page()by the preceding thread. EEH: Beginning: 'slot_reset' PCI 0011:01:00.0#10000: EEH: Invoking bnx2x->slot_reset() bnx2x: [bnx2x_io_slot_reset:14228(eth1)]IO slot reset initializing... bnx2x 0011:01:00.0: enabling device (0140 -> 0142) bnx2x: [bnx2x_io_slot_reset:14244(eth1)]IO slot reset --> driver unload Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc0080000025065fc Oops: Kernel access of bad area, sig: 11 [#1] ..... Call Trace: [c000000003c67a20] [c00800000250658c] bnx2x_io_slot_reset+0x204/0x610 [bnx2x] (unreliable) [c000000003c67af0] [c0000000000518a8] eeh_report_reset+0xb8/0xf0 [c000000003c67b60] [c000000000052130] eeh_pe_report+0x180/0x550 [c000000003c67c70] [c00000000005318c] eeh_handle_normal_event+0x84c/0xa60 [c000000003c67d50] [c000000000053a84] eeh_event_handler+0xf4/0x170 [c000000003c67da0] [c000000000194c58] kthread+0x1c8/0x1d0 [c000000003c67e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64To solve this issue, we need to verify page pool allocations beforefreeing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: receive: annotate data-race around receiving_counter.counterSyzkaller with KCSAN identified a data-race issue when accessingkeypair->receiving_counter.counter. Use READ_ONCE() and WRITE_ONCE()annotations to mark the data race as intentional. BUG: KCSAN: data-race in wg_packet_decrypt_worker / wg_packet_rx_poll write to 0xffff888107765888 of 8 bytes by interrupt on cpu 0: counter_validate drivers/net/wireguard/receive.c:321 [inline] wg_packet_rx_poll+0x3ac/0xf00 drivers/net/wireguard/receive.c:461 __napi_poll+0x60/0x3b0 net/core/dev.c:6536 napi_poll net/core/dev.c:6605 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6738 __do_softirq+0xc4/0x279 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] ptr_ring_consume_bh include/linux/ptr_ring.h:367 [inline] wg_packet_decrypt_worker+0x6c5/0x700 drivers/net/wireguard/receive.c:499 process_one_work kernel/workqueue.c:2633 [inline] ... read to 0xffff888107765888 of 8 bytes by task 3196 on cpu 1: decrypt_packet drivers/net/wireguard/receive.c:252 [inline] wg_packet_decrypt_worker+0x220/0x700 drivers/net/wireguard/receive.c:501 process_one_work kernel/workqueue.c:2633 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2706 worker_thread+0x525/0x730 kernel/workqueue.c:2787 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hsr: Fix uninit-value access in hsr_get_node()KMSAN reported the following uninit-value access issue [1]:=====================================================BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246 fill_frame_info net/hsr/hsr_forward.c:577 [inline] hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3548 [inline] dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560 __alloc_skb+0x318/0x740 net/core/skbuff.c:651 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787 packet_alloc_skb net/packet/af_packet.c:2936 [inline] packet_snd net/packet/af_packet.c:3030 [inline] packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bCPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023=====================================================If the packet type ID field in the Ethernet header is either ETH_P_PRP orETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()reads an invalid value as a sequence number. This causes the above issue.This patch fixes the issue by returning NULL if the Ethernet header is notfollowed by an HSR tag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: lpspi: Avoid potential use-after-free in probe()fsl_lpspi_probe() is allocating/disposing memory manually withspi_alloc_host()/spi_alloc_target(), but usesdevm_spi_register_controller(). In case of error after the latter call thememory will be explicitly freed in the probe function byspi_controller_put() call, but used afterwards by "devm" management outsideprobe() (spi_unregister_controller() <- devm_spi_unregister() below).Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070...Call trace: kernfs_find_ns kernfs_find_and_get_ns sysfs_remove_group sysfs_remove_groups device_remove_attrs device_del spi_unregister_controller devm_spi_unregister release_nodes devres_release_all really_probe driver_probe_device __device_attach_driver bus_for_each_drv __device_attach device_initial_probe bus_probe_device deferred_probe_work_func process_one_work worker_thread kthread ret_from_fork

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102A call to listxattr() with a buffer size = 0 returns the actualsize of the buffer needed for a subsequent call. When size > 0,nfs4_listxattr() does not return an error because eithergeneric_listxattr() or nfs4_listxattr_nfs4_label() consumesexactly all the bytes then size is 0 when callingnfs4_listxattr_nfs4_user() which then triggers the followingkernel BUG: [ 99.403778] kernel BUG at mm/usercopy.c:102! [ 99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP [ 99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1 [ 99.415827] Call trace: [ 99.415985] usercopy_abort+0x70/0xa0 [ 99.416227] __check_heap_object+0x134/0x158 [ 99.416505] check_heap_object+0x150/0x188 [ 99.416696] __check_object_size.part.0+0x78/0x168 [ 99.416886] __check_object_size+0x28/0x40 [ 99.417078] listxattr+0x8c/0x120 [ 99.417252] path_listxattr+0x78/0xe0 [ 99.417476] __arm64_sys_listxattr+0x28/0x40 [ 99.417723] invoke_syscall+0x78/0x100 [ 99.417929] el0_svc_common.constprop.0+0x48/0xf0 [ 99.418186] do_el0_svc+0x24/0x38 [ 99.418376] el0_svc+0x3c/0x110 [ 99.418554] el0t_64_sync_handler+0x120/0x130 [ 99.418788] el0t_64_sync+0x194/0x198 [ 99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',thus calling lisxattr() with size = 16 will trigger the bug.Add check on nfs4_listxattr() to return ERANGE error when it iscalled with size > 0 and the return value is greater than size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Do not register event handler until srpt device is fully setupUpon rare occasions, KASAN reports a use-after-free Writein srpt_refresh_port().This seems to be because an event handler is registered before thesrpt device is fully setup and a race condition upon error may leave apartially setup event handler in place.Instead, only register the event handler after srpt device initializationis complete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26874 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flipIt's possible that mtk_crtc->event is NULL inmtk_drm_crtc_finish_page_flip().pending_needs_vblank value is set by mtk_crtc->event, but inmtk_drm_crtc_atomic_flush(), it's is not guarded by the samelock in mtk_drm_finish_page_flip(), thus a race condition happens.Consider the following case:CPU1 CPU2step 1:mtk_drm_crtc_atomic_begin()mtk_crtc->event is not null, step 1: mtk_drm_crtc_atomic_flush: mtk_drm_crtc_update_config( !!mtk_crtc->event)step 2:mtk_crtc_ddp_irq ->mtk_drm_finish_page_flip:lockmtk_crtc->event set to null,pending_needs_vblank set to falseunlock pending_needs_vblank set to true, step 2: mtk_crtc_ddp_irq -> mtk_drm_finish_page_flip called again, pending_needs_vblank is still true //null pointerInstead of guarding the entire mtk_drm_crtc_atomic_flush(), it's moreefficient to just check if mtk_crtc->event is null before use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26876 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: adv7511: fix crash on irq during probeMoved IRQ registration down to end of adv7511_probe().If an IRQ already is pending during adv7511_probe(before adv7511_cec_init) then cec_received_msg_tscould crash using uninitialized data: Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5 Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP Call trace: cec_received_msg_ts+0x48/0x990 [cec] adv7511_cec_irq_process+0x1cc/0x308 [adv7511] adv7511_irq_process+0xd8/0x120 [adv7511] adv7511_irq_handler+0x1c/0x30 [adv7511] irq_thread_fn+0x30/0xa0 irq_thread+0x14c/0x238 kthread+0x190/0x1a8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: meson: Add missing clocks to axg_clk_regmapsSome clocks were missing from axg_clk_regmaps, which caused kernel panicduring cat /sys/kernel/debug/clk/clk_summary[ 57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc...[ 57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 57.436900] pc : regmap_read+0x1c/0x88[ 57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.445611] sp : ffff800082f1b690[ 57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70[ 57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000[ 57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000[ 57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff[ 57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000[ 57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100[ 57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24[ 57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710[ 57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000[ 57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000[ 57.519615] Call trace:[ 57.522030] regmap_read+0x1c/0x88[ 57.525393] clk_regmap_gate_is_enabled+0x3c/0xb0[ 57.530050] clk_core_is_enabled+0x44/0x120[ 57.534190] clk_summary_show_subtree+0x154/0x2f0[ 57.538847] clk_summary_show_subtree+0x220/0x2f0[ 57.543505] clk_summary_show_subtree+0x220/0x2f0[ 57.548162] clk_summary_show_subtree+0x220/0x2f0[ 57.552820] clk_summary_show_subtree+0x220/0x2f0[ 57.557477] clk_summary_show_subtree+0x220/0x2f0[ 57.562135] clk_summary_show_subtree+0x220/0x2f0[ 57.566792] clk_summary_show_subtree+0x220/0x2f0[ 57.571450] clk_summary_show+0x84/0xb8[ 57.575245] seq_read_iter+0x1bc/0x4b8[ 57.578954] seq_read+0x8c/0xd0[ 57.582059] full_proxy_read+0x68/0xc8[ 57.585767] vfs_read+0xb0/0x268[ 57.588959] ksys_read+0x70/0x108[ 57.592236] __arm64_sys_read+0x24/0x38[ 57.596031] invoke_syscall+0x50/0x128[ 57.599740] el0_svc_common.constprop.0+0x48/0xf8[ 57.604397] do_el0_svc+0x28/0x40[ 57.607675] el0_svc+0x34/0xb8[ 57.610694] el0t_64_sync_handler+0x13c/0x158[ 57.615006] el0t_64_sync+0x190/0x198[ 57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)[ 57.624668] ---[ end trace 0000000000000000 ]---[jbrunet: add missing Fixes tag]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is received on HIP08 devicesThe HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL, but the hardware can receive 1588 messages,and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, theaccess of hdev->ptp->flags will cause a kernel crash:[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge][ 5889.279101] sp : ffff800012c3bc50[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080[ 5889.378857] Call trace:[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge][ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3][ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3][ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3][ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3][ 5889.411084] napi_poll+0xcc/0x264[ 5889.415329] net_rx_action+0xd4/0x21c[ 5889.419911] __do_softirq+0x130/0x358[ 5889.424484] irq_exit+0x134/0x154[ 5889.428700] __handle_domain_irq+0x88/0xf0[ 5889.433684] gic_handle_irq+0x78/0x2c0[ 5889.438319] el1_irq+0xb8/0x140[ 5889.442354] arch_cpu_idle+0x18/0x40[ 5889.446816] default_idle_call+0x5c/0x1c0[ 5889.451714] cpuidle_idle_call+0x174/0x1b0[ 5889.456692] do_idle+0xc8/0x160[ 5889.460717] cpu_startup_entry+0x30/0xfc[ 5889.465523] secondary_start_kernel+0x158/0x1ec[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)[ 5889.477950] SMP: stopping secondary CPUs[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95[ 5890.522951] Starting crashdump kernel...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()Apply the same fix than ones found in :8d975c15c0cd ("ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()")1ca1ba465e55 ("geneve: make sure to pull inner header in geneve_rx()")We have to save skb->network_header in a temporary variablein order to be able to recompute the network_header pointerafter a pskb_inet_may_pull() call.pskb_inet_may_pull() makes sure the needed headers are in skb->head.syzbot reported:BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline] INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline] IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline] ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409 __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389 ipgre_rcv net/ipv4/ip_gre.c:411 [inline] gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447 gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163 ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:461 [inline] ip_rcv_finish net/ipv4/ip_input.c:449 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core net/core/dev.c:5534 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648 netif_receive_skb_internal net/core/dev.c:5734 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5793 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556 tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133 alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204 skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909 tun_build_skb drivers/net/tun.c:1686 [inline] tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055 call_write_iter include/linux/fs.h:2087 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb6b/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix DEVMAP_HASH overflow check on 32-bit archesThe devmap code allocates a number hash buckets equal to the next powerof two of the max_entries value provided when creating the map. Whenrounding up to the next power of two, the 32-bit variable storing thenumber of buckets can overflow, and the code checks for overflow bychecking if the truncated 32-bit value is equal to 0. However, on 32-bitarches the rounding up itself can overflow mid-way through, because itends up doing a left-shift of 32 bits on an unsigned long value. If thesize of an unsigned long is four bytes, this is undefined behaviour, sothere is no guarantee that we'll end up with a nice and tidy 0-value atthe end.Syzbot managed to turn this into a crash on arm32 by creating aDEVMAP_HASH with max_entries > 0x80000000 and then trying to update it.Fix this by moving the overflow check to before the rounding upoperation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: af_bluetooth: Fix deadlockAttemting to do sock_lock on .recvmsg may cause a deadlock as shownbellow, so instead of using sock_sock this uses sk_receive_queue.lockon bt_sock_ioctl to avoid the UAF:INFO: task kworker/u9:1:121 blocked for more than 30 seconds. Not tainted 6.7.6-lemon #183Workqueue: hci0 hci_rx_workCall Trace: __schedule+0x37d/0xa00 schedule+0x32/0xe0 __lock_sock+0x68/0xa0 ? __pfx_autoremove_wake_function+0x10/0x10 lock_sock_nested+0x43/0x50 l2cap_sock_recv_cb+0x21/0xa0 l2cap_recv_frame+0x55b/0x30a0 ? psi_task_switch+0xeb/0x270 ? finish_task_switch.isra.0+0x93/0x2a0 hci_rx_work+0x33a/0x3f0 process_one_work+0x13a/0x2f0 worker_thread+0x2f0/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe0/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26894 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()After unregistering the CPU idle device, the memory associated withit is not freed, leading to a memory leak:unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50Fix this by freeing the CPU idle device after unregistering it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix memory leak when starting APKmemleak reported this error: unreferenced object 0xd73d1180 (size 184): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.245s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00 ................ backtrace: [<5ca11420>] kmem_cache_alloc+0x20c/0x5ac [<127bdd74>] __alloc_skb+0x144/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4 [<69954f45>] __sys_sendmsg+0x64/0xa8 unreferenced object 0xce087000 (size 1024): comm "wpa_supplicant", pid 1559, jiffies 13006305 (age 964.246s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<9a993714>] __kmalloc_track_caller+0x230/0x600 [] kmalloc_reserve.constprop.0+0x30/0x74 [] __alloc_skb+0xa0/0x170 [] __netdev_alloc_skb+0x50/0x180 [<0f9fa1d5>] __ieee80211_beacon_get+0x290/0x4d4 [mac80211] [<7accd02d>] ieee80211_beacon_get_tim+0x54/0x18c [mac80211] [<41e25cc3>] wfx_start_ap+0xc8/0x234 [wfx] [<93a70356>] ieee80211_start_ap+0x404/0x6b4 [mac80211] [] nl80211_start_ap+0x76c/0x9e0 [cfg80211] [<47bd8b68>] genl_rcv_msg+0x198/0x378 [<453ef796>] netlink_rcv_skb+0xd0/0x130 [<6b7c977a>] genl_rcv+0x34/0x44 [<66b2d04d>] netlink_unicast+0x1b4/0x258 [] netlink_sendmsg+0x1e8/0x428 [] ____sys_sendmsg+0x1e0/0x274 [] ___sys_sendmsg+0x80/0xb4However, since the kernel is build optimized, it seems the stack is notaccurate. It appears the issue is related to wfx_set_mfp_ap(). The issueis obvious in this function: memory allocated by ieee80211_beacon_get()is never released. Fixing this leak makes kmemleak happy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev->serialIf kobject_add() is fail in bind_rdev_to_array(), 'rdev->serial' will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc f773277a): [<0000000058b0a453>] kmemleak_alloc+0x61/0xe0 [<00000000366adf14>] __kmalloc_large_node+0x15e/0x270 [<000000002e82961b>] __kmalloc_node.cold+0x11/0x7f [<00000000f206d60a>] kvmalloc_node+0x74/0x150 [<0000000034bf3363>] rdev_init_serial+0x67/0x170 [<0000000010e08fe9>] mddev_create_serial_pool+0x62/0x220 [<00000000c3837bf0>] bind_rdev_to_array+0x2af/0x630 [<0000000073c28560>] md_add_new_disk+0x400/0x9f0 [<00000000770e30ff>] md_ioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdev_ioctl+0x191/0x3f0 [<0000000085086a11>] vfs_ioctl+0x22/0x60 [<0000000018b656fe>] __x64_sys_ioctl+0xba/0xe0 [<00000000e54e675e>] do_syscall_64+0x71/0x150 [<000000008b0ad622>] entry_SYSCALL_64_after_hwframe+0x6c/0x74

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Reset IH OVERFLOW_CLEAR bitAllows us to detect subsequent IH ring buffer overflows as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: validate the parameters of bo mapping operations more clearlyVerify the parameters ofamdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface's parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected. As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete. But usb_deauthorize_interface() can't completeuntil the device lock has been released, and the lock won't bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot to wait for the attribute callback.Reported-and-tested by: Yue Sun Reported by: xingwei lee

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: netlink: access device through ctx instead of peerThe previous commit fixed a bug that led to a NULL peer->device beingdereferenced. It's actually easier and faster performance-wise toinstead get the device from ctx->wg. This semantically makes more sensetoo, since ctx->wg->peer_allowedips.seq is compared withctx->allowedips_seq, basing them both in ctx. This also acts as adefence in depth provision against freed peers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: esp: fix bad handling of pages from page_poolWhen the skb is reorganized during esp_output (!esp->inline), the pagescoming from the original skb fragments are supposed to be released backto the system through put_page. But if the skb fragment pages areoriginating from a page_pool, calling put_page on them will trigger apage_pool leak which will eventually result in a crash.This leak can be easily observed when using CONFIG_DEBUG_VM and doingipsec + gre (non offloaded) forwarding: BUG: Bad page state in process ksoftirqd/16 pfn:1451b6 page:00000000de2b8d32 refcount:0 mapcount:0 mapping:0000000000000000 index:0x1451b6000 pfn:0x1451b6 flags: 0x200000000000000(node=0|zone=2) page_type: 0xffffffff() raw: 0200000000000000 dead000000000040 ffff88810d23c000 0000000000000000 raw: 00000001451b6000 0000000000000001 00000000ffffffff 0000000000000000 page dumped because: page_pool leak Modules linked in: ip_gre gre mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat nf_nat xt_addrtype br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core overlay zram zsmalloc fuse [last unloaded: mlx5_core] CPU: 16 PID: 96 Comm: ksoftirqd/16 Not tainted 6.8.0-rc4+ #22 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x36/0x50 bad_page+0x70/0xf0 free_unref_page_prepare+0x27a/0x460 free_unref_page+0x38/0x120 esp_ssg_unref.isra.0+0x15f/0x200 esp_output_tail+0x66d/0x780 esp_xmit+0x2c5/0x360 validate_xmit_xfrm+0x313/0x370 ? validate_xmit_skb+0x1d/0x330 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x23e/0x350 __dev_queue_xmit+0x337/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x25e/0x580 iptunnel_xmit+0x19b/0x240 ip_tunnel_xmit+0x5fb/0xb60 ipgre_xmit+0x14d/0x280 [ip_gre] dev_hard_start_xmit+0xc3/0x1c0 __dev_queue_xmit+0x208/0xba0 ? nf_hook_slow+0x3f/0xd0 ip_finish_output2+0x1ca/0x580 ip_sublist_rcv_finish+0x32/0x40 ip_sublist_rcv+0x1b2/0x1f0 ? ip_rcv_finish_core.constprop.0+0x460/0x460 ip_list_rcv+0x103/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x1b3/0x2c0 napi_gro_receive+0xc8/0x200 gro_cell_poll+0x52/0x90 __napi_poll+0x25/0x1a0 net_rx_action+0x28e/0x300 __do_softirq+0xc3/0x276 ? sort_range+0x20/0x20 run_ksoftirqd+0x1e/0x30 smpboot_thread_fn+0xa6/0x130 kthread+0xcd/0x100 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x31/0x50 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork_asm+0x11/0x20 The suggested fix is to introduce a new wrapper (skb_page_unref) thatcovers page refcounting for page_pool pages as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/zcrypt: fix reference counting on zcrypt card objectsTests with hot-plugging crytpo cards on KVM guests with debugkernel build revealed an use after free for the load field ofthe struct zcrypt_card. The reason was an incorrect referencehandling of the zcrypt card object which could lead to a freeof the zcrypt card object while it was still in use.This is an example of the slab message: kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43 kernel: kmalloc_trace+0x3f2/0x470 kernel: zcrypt_card_alloc+0x36/0x70 [zcrypt] kernel: zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4] kernel: ap_device_probe+0x15c/0x290 kernel: really_probe+0xd2/0x468 kernel: driver_probe_device+0x40/0xf0 kernel: __device_attach_driver+0xc0/0x140 kernel: bus_for_each_drv+0x8c/0xd0 kernel: __device_attach+0x114/0x198 kernel: bus_probe_device+0xb4/0xc8 kernel: device_add+0x4d2/0x6e0 kernel: ap_scan_adapter+0x3d0/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43 kernel: kfree+0x37e/0x418 kernel: zcrypt_card_put+0x54/0x80 [zcrypt] kernel: ap_device_remove+0x4c/0xe0 kernel: device_release_driver_internal+0x1c4/0x270 kernel: bus_remove_device+0x100/0x188 kernel: device_del+0x164/0x3c0 kernel: device_unregister+0x30/0x90 kernel: ap_scan_adapter+0xc8/0x7c0 kernel: ap_scan_bus+0x5a/0x3b0 kernel: ap_scan_bus_wq_callback+0x40/0x60 kernel: process_one_work+0x26e/0x620 kernel: worker_thread+0x21c/0x440 kernel: kthread+0x150/0x168 kernel: __ret_from_fork+0x3c/0x58 kernel: ret_from_fork+0xa/0x30 kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff) kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88 kernel: Redzone 00000000885a74b0: bb bb bb bb bb bb bb bb ........ kernel: Object 00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk kernel: Object 00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5 kkkkkkkkkkhKkkk. kernel: Redzone 00000000885a7518: bb bb bb bb bb bb bb bb ........ kernel: Padding 00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZ kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2 kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux) kernel: Call Trace: kernel: [<00000000ca5ab5b8>] dump_stack_lvl+0x90/0x120 kernel: [<00000000c99d78bc>] check_bytes_and_report+0x114/0x140 kernel: [<00000000c99d53cc>] check_object+0x334/0x3f8 kernel: [<00000000c99d820c>] alloc_debug_processing+0xc4/0x1f8 kernel: [<00000000c99d852e>] get_partial_node.part.0+0x1ee/0x3e0 kernel: [<00000000c99d94ec>] ___slab_alloc+0xaf4/0x13c8 kernel: [<00000000c99d9e38>] __slab_alloc.constprop.0+0x78/0xb8 kernel: [<00000000c99dc8dc>] __kmalloc+0x434/0x590 kernel: [<00000000c9b4c0ce>] ext4_htree_store_dirent+0x4e/0x1c0 kernel: [<00000000c9b908a2>] htree_dirblock_to_tree+0x17a/0x3f0 kernel: ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26960 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: swap: fix race between free_swap_and_cache() and swapoff()There was previously a theoretical window where swapoff() could run andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread. This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_swap_and_cache()) to access the freed memory for swap_map.This is a theoretical problem and I haven't been able to provoke it from atest case. But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff(). There was an extra check in _swap_info_get() to confirm thatthe swap entry was not free. This isn't present in get_swap_device()because it doesn't make sense in general due to the race between gettingthe reference and swapoff. So I've added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor deriving this):--8<-----__swap_entry_free() might be the last user and result in"count == SWAP_HAS_CACHE".swapoff->try_to_unuse() will stop as soon as soon as si->inuse_pages==0.So the question is: could someone reclaim the folio and turnsi->inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill references by swap entries.Process 1 still references subpage 0 via swap entry.Process 2 still references subpage 1 via swap entry.Process 1 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHE[then, preempted in the hypervisor etc.]Process 2 quits. Calls free_swap_and_cache().-> count == SWAP_HAS_CACHEProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls__try_to_reclaim_swap().__try_to_reclaim_swap()->folio_free_swap()->delete_from_swap_cache()->put_swap_folio()->free_swap_slot()->swapcache_free_entries()->swap_entry_free()->swap_range_free()->...WRITE_ONCE(si->inuse_pages, si->inuse_pages - nr_entries);What stops swapoff to succeed after process 2 reclaimed the swap cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8<-----

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshapeFor raid456, if reshape is still in progress, then IO across reshapeposition will wait for reshape to make progress. However, for dm-raid,in following cases reshape will never make progress hence IO will hang:1) the array is read-only;2) MD_RECOVERY_WAIT is set;3) MD_RECOVERY_FROZEN is set;After commit c467e97f079f ("md/raid6: use valid sector values to determineif an I/O should wait on the reshape") fix the problem that IO acrossreshape position doesn't wait for reshape, the dm-raid testshell/lvconvert-raid-reshape.sh start to hang:[root@fedora ~]# cat /proc/979/stack[<0>] wait_woken+0x7d/0x90[<0>] raid5_make_request+0x929/0x1d70 [raid456][<0>] md_handle_request+0xc2/0x3b0 [md_mod][<0>] raid_map+0x2c/0x50 [dm_raid][<0>] __map_bio+0x251/0x380 [dm_mod][<0>] dm_submit_bio+0x1f0/0x760 [dm_mod][<0>] __submit_bio+0xc2/0x1c0[<0>] submit_bio_noacct_nocheck+0x17f/0x450[<0>] submit_bio_noacct+0x2bc/0x780[<0>] submit_bio+0x70/0xc0[<0>] mpage_readahead+0x169/0x1f0[<0>] blkdev_readahead+0x18/0x30[<0>] read_pages+0x7c/0x3b0[<0>] page_cache_ra_unbounded+0x1ab/0x280[<0>] force_page_cache_ra+0x9e/0x130[<0>] page_cache_sync_ra+0x3b/0x110[<0>] filemap_get_pages+0x143/0xa30[<0>] filemap_read+0xdc/0x4b0[<0>] blkdev_read_iter+0x75/0x200[<0>] vfs_read+0x272/0x460[<0>] ksys_read+0x7a/0x170[<0>] __x64_sys_read+0x1c/0x30[<0>] do_syscall_64+0xc6/0x230[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74This is because reshape can't make progress.For md/raid, the problem doesn't exist because register new sync_threaddoesn't rely on the IO to be done any more:1) If array is read-only, it can switch to read-write by ioctl/sysfs;2) md/raid never set MD_RECOVERY_WAIT;3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold 'reconfig_mutex', hence it can be cleared and reshape can continue by sysfs api 'sync_action'.However, I'm not sure yet how to avoid the problem in dm-raid yet. Thispatch on the one hand make sure raid_message() can't changesync_thread() through raid_message() after presuspend(), on the otherhand detect the above 3 cases before wait for IO do be done indm_suspend(), and let dm-raid requeue those IO.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: qcom: gcc-ipq8074: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fat: fix uninitialized field in nostale filehandlesWhen fat_encode_fh_nostale() encodes file handle without a parent itstores only first 10 bytes of the file handle. However the length of thefile handle must be a multiple of 4 so the file handle is actually 12bytes long and the last two bytes remain uninitialized. This is notgreat at we potentially leak uninitialized information with the handleto userspace. Properly initialize the full handle length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - resolve race condition during AER recoveryDuring the PCI AER system's error recovery process, the kernel drivermay encounter a race condition with freeing the reset_data structure'smemory. If the device restart will take more than 10 seconds the functionscheduling that restart will exit due to a timeout, and the reset_datastructure will be freed. However, this data structure is used forcompletion notification after the restart is completed, which leadsto a UAF bug.This results in a KFENCE bug notice. BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat] Use-after-free read at 0x00000000bc56fddf (in kfence-#142): adf_device_reset_worker+0x38/0xa0 [intel_qat] process_one_work+0x173/0x340To resolve this race condition, the memory associated to the containerof the work_struct is freed on the worker if the timeout expired,otherwise on the function that schedules the worker.The timeout detection can be done by checking if the caller isstill waiting for completion or not by using completion_done() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas an inode number with the invalid value of zero, which was not checked.The reason this causes the out of bounds access is due to followingsequence of events:1. Fill_meta_index() is called to allocate (via empty_meta_index()) and fill a metadata index. It however suffers a data read error and aborts, invalidating the newly returned empty metadata index. It does this by setting the inode number of the index to zero, which means unused (zero is not a valid inode number).2. When fill_meta_index() is subsequently called again on another read operation, locate_meta_index() returns the previous index because it matches the inode number of 0. Because this index has been returned it is expected to have been filled, and because it hasn't been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis not zero when the inode is created and returns -EINVAL if it is.[phillip@squashfs.org.uk: whitespace fix]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: Do a runtime PM get on controllers during probemt8183-mfgcfg has a mutual dependency with genpd during the probingstage, which leads to a deadlock in the following call stack:CPU0: genpd_lock --> clk_prepare_lockgenpd_power_off_work_fn() genpd_lock() generic_pm_domain::power_off() clk_unprepare() clk_prepare_lock()CPU1: clk_prepare_lock --> genpd_lockclk_register() __clk_core_init() clk_prepare_lock() clk_pm_runtime_get() genpd_lock()Do a runtime PM get at the probe function to make sure clk_register()won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,do this on all mediatek clock controller probings because we don'tbelieve this would cause any regression.Verified on MT8183 and MT8192 Chromebooks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored or redirected to self we hit a qdisc lock deadlock.See trace below.[..... other info removed for brevity....][ 82.890906][ 82.890906] ============================================[ 82.890906] WARNING: possible recursive locking detected[ 82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G W[ 82.890906] --------------------------------------------[ 82.890906] ping/418 is trying to acquire lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] but task is already holding lock:[ 82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:__dev_queue_xmit+0x1778/0x3550[ 82.890906][ 82.890906] other info that might help us debug this:[ 82.890906] Possible unsafe locking scenario:[ 82.890906][ 82.890906] CPU0[ 82.890906] ----[ 82.890906] lock(&sch->q.lock);[ 82.890906] lock(&sch->q.lock);[ 82.890906][ 82.890906] *** DEADLOCK ***[ 82.890906][..... other info removed for brevity....]Example setup (eth0->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0Another example(eth0->eth1->eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \ action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix memleak in map from abort pathThe delete set command does not rely on the transaction object forelement removal, therefore, a combination of delete element + delete setfrom the abort path could result in restoring twice the refcount of themapping.Check for inactive element in the next generation for the delete elementcommand in the abort path, skip restoring state if next generation bithas been already cleared. This is similar to the activate logic usingthe set walk iterator.[ 6170.286929] ------------[ cut here ]------------[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287071] Modules linked in: [...][ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 <0f> 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100[ 6170.287940] FS: 0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000[ 6170.287948] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0[ 6170.287962] Call Trace:[ 6170.287967] [ 6170.287973] ? __warn+0x9f/0x1a0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.287986] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288092] ? report_bug+0x1b1/0x1e0[ 6170.288104] ? handle_bug+0x3c/0x70[ 6170.288112] ? exc_invalid_op+0x17/0x40[ 6170.288120] ? asm_exc_invalid_op+0x1a/0x20[ 6170.288132] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288243] ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables][ 6170.288366] ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables][ 6170.288483] nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tun: limit printing rate when illegal packet received by tun devvhost_worker will call tun call backs to receive packets. If too manyillegal packets arrives, tun_do_read will keep dumping packet contents.When console is enabled, it will costs much more cpu time to dumppacket and soft lockup will be detected.net_ratelimit mechanism can be used to limit the dumping rate.PID: 33036 TASK: ffff949da6f20000 CPU: 23 COMMAND: "vhost-32980" #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253 #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3 #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e #3 [fffffe00003fced0] do_nmi at ffffffff8922660d #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663 [exception RIP: io_serial_in+20] RIP: ffffffff89792594 RSP: ffffa655314979e8 RFLAGS: 00000002 RAX: ffffffff89792500 RBX: ffffffff8af428a0 RCX: 0000000000000000 RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff8af428a0 RBP: 0000000000002710 R8: 0000000000000004 R9: 000000000000000f R10: 0000000000000000 R11: ffffffff8acbf64f R12: 0000000000000020 R13: ffffffff8acbf698 R14: 0000000000000058 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #5 [ffffa655314979e8] io_serial_in at ffffffff89792594 #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470 #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6 #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605 #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558 #10 [ffffa65531497ac8] console_unlock at ffffffff89316124 #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07 #12 [ffffa65531497b68] printk at ffffffff89318306 #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765 #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun] #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun] #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net] #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost] #18 [ffffa65531497f10] kthread at ffffffff892d2e72 #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv->state_lock`, any scheduledaRFS works are canceled using the `cancel_work_sync` function,which waits for the work to end if it has already started.However, while waiting for the work handler, the handler willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker's responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I------------------------------------------------------ethtool/386089 is trying to acquire lock:ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0but task is already holding lock:ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20-> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4eother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK ***3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]stack backtrace:CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: incorrect pppoe tuplepppoe traffic reaching ingress path does not match the flowtable entrybecause the pppoe header is expected to be at the network header offset.This bug causes a mismatch in the flow table lookup, so pppoe packetsenter the classical forwarding path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: validate pppoe headerEnsure there is sufficient room to access the protocol field of thePPPoe header. Validate it once before the flowtable lookup, then use ahelper function to access protocol field.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()nft_unregister_obj() can concurrent with __nft_obj_type_get(),and there is not any protection when iterate over nf_tables_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27020 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()nft_unregister_expr() can concurrent with __nft_expr_type_get(),and there is not any protection when iterate over nf_tables_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix clk_core_get NULL dereferenceIt is possible for clk_core_get to dereference a NULL in the followingsequence:clk_core_get() of_clk_get_hw_from_clkspec() __of_clk_get_hw_from_provider() __clk_get_hw()__clk_get_hw() can return NULL which is dereferenced by clk_core_get() athw->core.Prior to commit dde4eff47c82 ("clk: Look for parents with clkdev basedclk_lookups") the check IS_ERR_OR_NULL() was performed which would havecaught the NULL.Reading the description of this function it talks about returning NULL butthat cannot be so at the moment.Update the function to check for hw before dereferencing it and return NULLif hw is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix NULL checks for adev->dm.dc in amdgpu_dm_fini()Since 'adev->dm.dc' in amdgpu_dm_fini() might turn out to be NULLbefore the call to dc_enable_dmub_notifications(), checkbeforehand to ensure there will not be a possible NULL-ptr-derefthere.Also, since commit 1e88eb1b2c25 ("drm/amd/display: DropCONFIG_DRM_AMD_DC_HDCP") there are two separate checks for NULL in'adev->dm.dc' before dc_deinit_callbacks() and dc_dmub_srv_destroy().Clean up by combining them all under one 'if'.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in 'dcn10_set_output_transfer_func()'The 'stream' pointer is used in dcn10_set_output_transfer_func() beforethe check if 'stream' is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check 'stream' (see line 1875)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: flower: handle acti_netdevs allocation failureThe kmalloc_array() in nfp_fl_lag_do_work() will return null, ifthe physical memory has run out. As a result, if we dereferencethe acti_netdevs, the null pointer dereference bugs will happen.This patch adds a check to judge whether allocation failure occurs.If it happens, the delayed work will be rescheduled and try again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27054 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix double module refcount decrementOnce the discipline is associated with the device, deleting the devicetakes care of decrementing the module's refcount. Doing it manually onthis error path causes refcount to artificially decrease on each errorwhile it should just stay the same.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: ensure offloading TID queue existsThe resume code path assumes that the TX queue for the offloading TIDhas been configured. At resume time it then tries to sync the writepointer as it may have been updated by the firmware.In the unusual event that no packets have been send on TID 0, the queuewill not have been allocated and this causes a crash. Fix this byensuring the queue exist at suspend time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau: lock the client object tree.It appears the client object tree has no locking unless I've missedsomething else. Fix races around adding/removing client objects,mostly vram bar mappings. 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 <48> 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007[ 4562.099528] FS: 00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000[ 4562.099534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4562.099544] Call Trace:[ 4562.099555] [ 4562.099573] ? die_addr+0x36/0x90[ 4562.099583] ? exc_general_protection+0x246/0x4a0[ 4562.099593] ? asm_exc_general_protection+0x26/0x30[ 4562.099600] ? nvkm_object_search+0x1d/0x70 [nouveau][ 4562.099730] nvkm_ioctl+0xa1/0x250 [nouveau][ 4562.099861] nvif_object_map_handle+0xc8/0x180 [nouveau][ 4562.099986] nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau][ 4562.100156] ? dma_resv_test_signaled+0x26/0xb0[ 4562.100163] ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm][ 4562.100182] ? __mutex_unlock_slowpath+0x2a/0x270[ 4562.100189] nouveau_ttm_fault+0x69/0xb0 [nouveau][ 4562.100356] __do_fault+0x32/0x150[ 4562.100362] do_fault+0x7c/0x560[ 4562.100369] __handle_mm_fault+0x800/0xc10[ 4562.100382] handle_mm_fault+0x17c/0x3e0[ 4562.100388] do_user_addr_fault+0x208/0x860[ 4562.100395] exc_page_fault+0x7f/0x200[ 4562.100402] asm_exc_page_fault+0x26/0x30[ 4562.100412] RIP: 0033:0x9b9870[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 <44> 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000[ 4562.100446] [ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27065 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: do not compare internal table flags on updatesRestore skipping transaction if table update does not modify flags.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Remove useless locks in usbtv_video_free()Remove locks calls in usbtv_video_free() becauseare useless and may led to a deadlock as reported here:https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000Also remove usbtv_stop() call since it will be called whenunregistering the device.Before 'c838530d230b' this issue would only be noticed if youdisconnect while streaming and now it is noticeable even whendisconnecting while not streaming.[hverkuil: fix minor spelling mistake in log message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx: csc/scaler: fix v4l2_ctrl_handler memory leakFree the memory allocated in v4l2_ctrl_handler_init on release.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: fix some memleaks in tpg_allocIn tpg_alloc, resources should be deallocated in each and everyerror-handling paths, since they are allocated in for statements.Otherwise there would be memleaks because tpg_free is called only whentpg_alloc return 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27388 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix some memleaks in gssx_dec_option_arrayThe creds and oa->data need to be freed in the error-handling paths aftertheir allocation. So this patch add these deallocations in thecorresponding paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27393 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Add missing skb_mark_for_recycleNotice that skb_mark_for_recycle() is introduced later than fixes tag incommit 6a5bcd84e886 ("page_pool: Allow drivers to hint on SKB recycling").It is believed that fixes tag were missing a call to page_pool_release_page()between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().Since v6.6 the call page_pool_release_page() were removed (incommit 535b9c61bdef ("net: page_pool: hide page_pool_release_page()")and remaining callers converted (in commit 6bfef2ec0172 ("Merge branch'net-page_pool-remove-page_pool_release_page'")).This leak became visible in v6.8 via commit dba1b8a7ab68 ("mm/page_pool: catchpage_pool memory leaks").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27395 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix Use-After-Free in ovs_ct_exitSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversalof ovs_ct_limit_exit, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27396 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gtp: Fix Use-After-Free in gtp_dellinkSince call_rcu, which is called in the hlist_for_each_entry_rcu traversalof gtp_dellink, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27399 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeoutThere is a race condition between l2cap_chan_timeout() andl2cap_chan_del(). When we use l2cap_chan_del() to delete thechannel, the chan->conn will be set to null. But the conn couldbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().As a result the null pointer dereference bug will happen. TheKASAN report triggered by POC is shown below:[ 472.074580] ==================================================================[ 472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0[ 472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7[ 472.075308][ 472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36[ 472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.075308] Workqueue: events l2cap_chan_timeout[ 472.075308] Call Trace:[ 472.075308] [ 472.075308] dump_stack_lvl+0x137/0x1a0[ 472.075308] print_report+0x101/0x250[ 472.075308] ? __virt_addr_valid+0x77/0x160[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_report+0x139/0x170[ 472.075308] ? mutex_lock+0x68/0xc0[ 472.075308] kasan_check_range+0x2c3/0x2e0[ 472.075308] mutex_lock+0x68/0xc0[ 472.075308] l2cap_chan_timeout+0x181/0x300[ 472.075308] process_one_work+0x5d2/0xe00[ 472.075308] worker_thread+0xe1d/0x1660[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] kthread+0x2b7/0x350[ 472.075308] ? pr_cont_work+0x5e0/0x5e0[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork+0x4d/0x80[ 472.075308] ? kthread_blkcg+0xd0/0xd0[ 472.075308] ret_from_fork_asm+0x11/0x20[ 472.075308] [ 472.075308] ==================================================================[ 472.094860] Disabling lock debugging due to kernel taint[ 472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158[ 472.096136] #PF: supervisor write access in kernel mode[ 472.096136] #PF: error_code(0x0002) - not-present page[ 472.096136] PGD 0 P4D 0[ 472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI[ 472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G B 6.9.0-rc5-00356-g78c0094a146b #36[ 472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4[ 472.096136] Workqueue: events l2cap_chan_timeout[ 472.096136] RIP: 0010:mutex_lock+0x88/0xc0[ 472.096136] Code: be 08 00 00 00 e8 f8 23 1f fd 4c 89 f7 be 08 00 00 00 e8 eb 23 1f fd 42 80 3c 23 00 74 08 48 88[ 472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246[ 472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865[ 472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78[ 472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f[ 472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000[ 472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00[ 472.096136] FS: 0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000[ 472.096136] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0[ 472.096136] Call Trace:[ 472.096136] [ 472.096136] ? __die_body+0x8d/0xe0[ 472.096136] ? page_fault_oops+0x6b8/0x9a0[ 472.096136] ? kernelmode_fixup_or_oops+0x20c/0x2a0[ 472.096136] ? do_user_addr_fault+0x1027/0x1340[ 472.096136] ? _printk+0x7a/0xa0[ 472.096136] ? mutex_lock+0x68/0xc0[ 472.096136] ? add_taint+0x42/0xd0[ 472.096136] ? exc_page_fault+0x6a/0x1b0[ 472.096136] ? asm_exc_page_fault+0x26/0x30[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] ? mutex_lock+0x88/0xc0[ 472.096136] ? mutex_lock+0x75/0xc0[ 472.096136] l2cap_chan_timeo---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27403 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_flow_offload: reset dst in route object after setting up flowdst is transferred to the flow object, route object does not own itanymore. Reset dst in route object, otherwise if flow_offload_add()fails, error path releases dst twice, leading to a refcount underflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27416 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUESTIf we received HCI_EV_IO_CAPA_REQUEST whileHCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remotedoes support SSP since otherwise this event shouldn't be generated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27435 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: fix reconnection fail due to reserved tag allocationWe found a issue on production environment while using NVMe over RDMA,admin_q reconnect failed forever while remote target and network is ok.After dig into it, we found it may caused by a ABBA deadlock due to tagallocation. In my case, the tag was hold by a keep alive requestwaiting inside admin_q, as we quiesced admin_q while reset ctrl, so therequest maked as idle and will not process before reset success. Asfabric_q shares tagset with admin_q, while reconnect remote target, weneed a tag for connect command, but the only one reserved tag was heldby keep alive command which waiting inside admin_q. As a result, wefailed to reconnect admin_q forever. In order to fix this issue, Ithink we should keep two reserved tags for admin queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27436 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Stop parsing channels bits when all channels are found.If a usb audio device sets more bits than the amount of channelsit could write outside of the map array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-33621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb->sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS: 0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg packet_snd //skb->sk is packet sk __dev_queue_xmit __dev_xmit_skb //q->enqueue is not NULL __qdisc_run sch_direct_xmit dev_hard_start_xmit ipvlan_start_xmit ipvlan_xmit_mode_l3 //l3 mode ipvlan_process_outbound //vepa flag ipvlan_process_v6_outbound ip6_local_out __ip6_finish_output ip6_finish_output2 //multicast packet sk_mc_loop //sk->sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: region: add owner module and take its refcountThe current implementation of the fpga region assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the regionduring programming if the parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_regionstruct and use it to take the module's refcount. Modify the functions forregistering a region to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the region as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a region without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm-raid: really frozen sync_thread during suspend1) commit f52f5c71f3d4 ("md: fix stopping sync thread") remove MD_RECOVERY_FROZEN from __md_stop_writes() and doesn't realize that dm-raid relies on __md_stop_writes() to frozen sync_thread indirectly. Fix this problem by adding MD_RECOVERY_FROZEN in md_stop_writes(), and since stop_sync_thread() is only used for dm-raid in this case, also move stop_sync_thread() to md_stop_writes().2) The flag MD_RECOVERY_FROZEN doesn't mean that sync thread is frozen, it only prevent new sync_thread to start, and it can't stop the running sync thread; In order to frozen sync_thread, after seting the flag, stop_sync_thread() should be used.3) The flag MD_RECOVERY_FROZEN doesn't mean that writes are stopped, use it as condition for md_stop_writes() in raid_postsuspend() doesn't look correct. Consider that reentrant stop_sync_thread() do nothing, always call md_stop_writes() in raid_postsuspend().4) raid_message can set/clear the flag MD_RECOVERY_FROZEN at anytime, and if MD_RECOVERY_FROZEN is cleared while the array is suspended, new sync_thread can start unexpected. Fix this by disallow raid_message() to change sync_thread status during suspend.Note that after commit f52f5c71f3d4 ("md: fix stopping sync thread"), thetest shell/lvconvert-raid-reshape.sh start to hang in stop_sync_thread(),and with previous fixes, the test won't hang there anymore, however, thetest will still fail and complain that ext4 is corrupted. And with thispatch, the test won't hang due to stop_sync_thread() or fail due to ext4is corrupted anymore. However, there is still a deadlock related todm-raid456 that will be fixed in following patches.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ll_temac: platform_get_resource replaced by wrong functionThe function platform_get_resource was replaced withdevm_platform_ioremap_resource_byname and is called using 0 as name.This eventually ends up in platform_get_resource_byname in the callstack, where it causes a null pointer in strcmp. if (type == resource_type(r) && !strcmp(r->name, name))It should have been replaced with devm_platform_ioremap_resource.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Keep xfd_state in sync with MSR_IA32_XFDCommit 672365477ae8 ("x86/fpu: Update XFD state where required") andcommit 8bf26758ca96 ("x86/fpu: Add XFD state to fpstate") introduced aper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, inorder to avoid unnecessary writes to the MSR.On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, whichwipes out any stale state. But the per CPU cached xfd value is notreset, which brings them out of sync.As a consequence a subsequent xfd_update_state() might fail to updatethe MSR which in turn can result in XRSTOR raising a #NM in kernelspace, which crashes the kernel.To fix this, introduce xfd_set_state() to write xfd_state togetherwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Mark target gfn of emulated atomic instruction as dirtyWhen emulating an atomic access on behalf of the guest, mark the targetgfn dirty if the CMPXCHG by KVM is attempted and doesn't fault. Thisfixes a bug where KVM effectively corrupts guest memory during livemigration by writing to guest memory without informing userspace that thepage is dirty.Marking the page dirty got unintentionally dropped when KVM's emulatedCMPXCHG was converted to do a user access. Before that, KVM explicitlymapped the guest page into kernel memory, and marked the page dirty duringthe unmap phase.Mark the page dirty even if the CMPXCHG fails, as the old data is writtenback on failure, i.e. the page is still written. The value written isguaranteed to be the same because the operation is atomic, but KVM's ABIis that all writes are dirty logged regardless of the value written. Andmore importantly, that's what KVM did before the buggy commit.Huge kudos to the folks on the Cc list (and many others), who did all theactual work of triaging and debugging.base-commit: 6769ea8da8a93ed4630f1ce64df6aafcaabfce64

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35805 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm snapshot: fix lockup in dm_exception_table_exitThere was reported lockup when we exit a snapshot with many exceptions.Fix this by adding "cond_resched" to the loop that frees the exceptions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix corruption during on-line resizeWe observed a corruption during on-line resize of a file system that islarger than 16 TiB with 4k block size. With having more then 2^32 blocksresize_inode is turned off by default by mke2fs. The issue can bereproduced on a smaller file system for convenience by explicitlyturning off resize_inode. An on-line resize across an 8 GiB boundary (thesize of a meta block group in this setup) then leads to a corruption: dev=/dev/ # should be >= 16 GiB mkdir -p /corruption /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15)) mount -t ext4 $dev /corruption dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15)) sha1sum /corruption/test # 79d2658b39dcfd77274e435b0934028adafaab11 /corruption/test /sbin/resize2fs $dev $((2*2**21)) # drop page cache to force reload the block from disk echo 1 > /proc/sys/vm/drop_caches sha1sum /corruption/test # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3 /corruption/test2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks perblock group and 2^6 are the number of block groups that make a metablock group.The last checksum might be different depending on how the file is laidout across the physical blocks. The actual corruption occurs at physicalblock 63*2^15 = 2064384 which would be the location of the backup of themeta block group's block descriptor. During the on-line resize the filesystem will be converted to meta_bg starting at s_first_meta_bg which is2 in the example - meaning all block groups after 16 GiB. However, inext4_flex_group_add we might add block groups that are not part of thefirst meta block group yet. In the reproducer we achieved this bysubstracting the size of a whole block group from the point where themeta block group would start. This must be considered when updating thebackup block group descriptors to follow the non-meta_bg layout. The fixis to add a test whether the group to add is already part of the metablock group or not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don't call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding 'reconfig_mutex', this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by'reconfig_mutex'.However, hold 'reconfig_mutex' here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b ("md: refactoridle/frozen_sync_thread() to fix deadlock").Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we've overwritten it with the data it's supposed to havein it will allow a simultaneous reader to see old data. Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vt: fix unicode buffer corruption when deleting charactersThis is the same issue that was fixed for the VGA text buffer in commit39cdb68c64d8 ("vt: fix memory overlapping when deleting chars in thebuffer"). The cure is also the same i.e. replace memcpy() with memmove()due to the overlaping buffers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35825 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: ncm: Fix handling of zero block length packetsWhile connecting to a Linux host with CDC_NCM_NTB_DEF_SIZE_TXset to 65536, it has been observed that we receive short packets,which come at interval of 5-10 seconds sometimes and have blocklength zero but still contain 1-2 valid datagrams present.According to the NCM spec:"If wBlockLength = 0x0000, the block is terminated by ashort packet. In this case, the USB transfer must stillbe shorter than dwNtbInMaxSize or dwNtbOutMaxSize. Ifexactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent,and the size is a multiple of wMaxPacketSize for thegiven pipe, then no ZLP shall be sent.wBlockLength= 0x0000 must be used with extreme care, becauseof the possibility that the host and device may get out ofsync, and because of test issues.wBlockLength = 0x0000 allows the sender to reduce latency bystarting to send a very large NTB, and then shortening it whenthe sender discovers that there's not sufficient data to justifysending a large NTB"However, there is a potential issue with the current implementation,as it checks for the occurrence of multiple NTBs in a singlegiveback by verifying if the leftover bytes to be processed is zeroor not. If the block length reads zero, we would process the sameNTB infintely because the leftover bytes is never zero and it leadsto a crash. Fix this by bailing out if block length reads zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/lima: fix a memleak in lima_heap_allocWhen lima_vm_map_bo fails, the resources need to be deallocated, orthere will be memleaks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: tc358743: register v4l2 async device only after successful setupEnsure the device has been setup correctly before registering the v4l2async device, thus allowing userspace to access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: Fix a memory leak related to the queue command DMAThis dma_alloc_coherent() is undone neither in the remove function, nor inthe error handling path of fsl_qdma_probe().Switch to the managed version to fix both issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: clear BM pool before initializationRegister value persist after booting the kernel usingkexec which results in kernel panic. Thus clear theBM pool registers before initialisation to fix the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh->arp_queue while waiting for an arpreply. Where original skb's skb->dev can be different to neigh'sneigh->dev. For instance in case of bridging dnated skb from one veth toanother, the skb would be added to a neigh->arp_queue of the bridge.As skb->dev can be reset back to nf_bridge->physindev and used, and asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn't cleanup skbs fromdifferent device's neigh queue) we can crash on e.g. this stack:arp_process neigh_update skb = __skb_dequeue(&neigh->arp_queue) neigh_resolve_output(..., skb) ... br_nf_dev_xmit br_nf_pre_routing_finish_bridge_slow skb->dev = nf_bridge->physindev br_handle_frame_finishLet's use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don't get it and drop skb.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35845 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dbg-tlv: ensure NUL terminationThe iwl_fw_ini_debug_info_tlv is used as a string, so we mustensure the string is terminated correctly before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v3-its: Prevent double free on errorThe error handling path in its_vpe_irq_domain_alloc() causes a double freewhen its_vpe_init() fails after successfully allocating at least oneinterrupt. This happens because its_vpe_irq_domain_free() frees theinterrupts along with the area bitmap and the vprop_page andits_vpe_irq_domain_alloc() subsequently frees the area bitmap and thevprop_page again.Fix this by unconditionally invoking its_vpe_irq_domain_free() whichhandles all cases correctly and by removing the bitmap/vprop_page freeingfrom its_vpe_irq_domain_alloc().[ tglx: Massaged change log ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eeprom: at24: fix memory corruption race conditionIf the eeprom is not accessible, an nvmem device will be registered, theread will fail, and the device will be torn down. If another driveraccesses the nvmem device after the teardown, it will referenceinvalid memory.Move the failure point before registering the nvmem device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35849 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix information leak in btrfs_ioctl_logical_to_ino()Syzbot reported the following information leak for inbtrfs_ioctl_logical_to_ino(): BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x110 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Uninit was created at: __kmalloc_large_node+0x231/0x370 mm/slub.c:3921 __do_kmalloc_node mm/slub.c:3954 [inline] __kmalloc_node+0xb07/0x1060 mm/slub.c:3973 kmalloc_node include/linux/slab.h:648 [inline] kvmalloc_node+0xc0/0x2d0 mm/util.c:634 kvmalloc include/linux/slab.h:766 [inline] init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779 btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480 btrfs_ioctl+0x714/0x1260 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890 __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890 x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Bytes 40-65535 of 65536 are uninitialized Memory access of size 65536 starts at ffff888045a40000This happens, because we're copying a 'struct btrfs_data_container' backto user-space. This btrfs_data_container is allocated in'init_data_container()' via kvmalloc(), which does not zero-fill thememory.Fix this by using kvzalloc() which zeroes out the memory on allocation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: qca: fix NULL-deref on non-serdev suspendQualcomm ROME controllers can be registered from the Bluetooth linediscipline and in this case the HCI UART serdev pointer is NULL.Add the missing sanity check to prevent a NULL-pointer dereference whenwakeup() is called for a non-serdev controller during suspend.Just return true for now to restore the original behaviour and addressthe crash with pre-6.2 kernels, which do not have commit e9b3e5b8c657("Bluetooth: hci_qca: only assign wakeup with serial port support") thatcauses the crash to happen already at setup() time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak when canceling rehash workThe rehash delayed work is rescheduled with a delay if the number ofcredits at end of the work is not negative as supposedly it means thatthe migration ended. Otherwise, it is rescheduled immediately.After "mlxsw: spectrum_acl_tcam: Fix possible use-after-free duringrehash" the above is no longer accurate as a non-negative number ofcredits is no longer indicative of the migration being done. It can alsohappen if the work encountered an error in which case the migration willresume the next time the work is scheduled.The significance of the above is that it is possible for the work to bepending and associated with hints that were allocated when the migrationstarted. This leads to the hints being leaked [1] when the work iscanceled while pending as part of ACL region dismantle.Fix by freeing the hints if hints are associated with a work that wascanceled while pending.Blame the original commit since the reliance on not having a pendingwork associated with hints is fragile.[1]unreferenced object 0xffff88810e7c3000 (size 256): comm "kworker/0:16", pid 176, jiffies 4295460353 hex dump (first 32 bytes): 00 30 95 11 81 88 ff ff 61 00 00 00 00 00 00 80 .0......a....... 00 00 61 00 40 00 00 00 00 00 00 00 04 00 00 00 ..a.@........... backtrace (crc 2544ddb9): [<00000000cf8cfab3>] kmalloc_trace+0x23f/0x2a0 [<000000004d9a1ad9>] objagg_hints_get+0x42/0x390 [<000000000b143cf3>] mlxsw_sp_acl_erp_rehash_hints_get+0xca/0x400 [<0000000059bdb60a>] mlxsw_sp_acl_tcam_vregion_rehash_work+0x868/0x1160 [<00000000e81fd734>] process_one_work+0x59c/0xf20 [<00000000ceee9e81>] worker_thread+0x799/0x12c0 [<00000000bda6fe39>] kthread+0x246/0x300 [<0000000070056d23>] ret_from_fork+0x34/0x70 [<00000000dea2b93e>] ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak during rehashThe rehash delayed work migrates filters from one region to another.This is done by iterating over all chunks (all the filters with the samepriority) in the region and in each chunk iterating over all thefilters.If the migration fails, the code tries to migrate the filters back tothe old region. However, the rollback itself can also fail in which caseanother migration will be erroneously performed. Besides the fact thatthis ping pong is not a very good idea, it also creates a problem.Each virtual chunk references two chunks: The currently used one('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration thefirst holds the chunk we want to migrate filters to and the second holdsthe chunk we are migrating filters from.The code currently assumes - but does not verify - that the backup chunkdoes not exist (NULL) if the currently used chunk does not reference thetarget region. This assumption breaks when we are trying to rollback arollback, resulting in the backup chunk being overwritten and leaked[1].Fix by not rolling back a failed rollback and add a warning to avoidfuture cases.[1]WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20Modules linked in:CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G W 6.9.0-rc2-custom-00784-gc6a05c468a0b #14Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:parman_destroy+0x17/0x20[...]Call Trace: mlxsw_sp_acl_atcam_region_fini+0x19/0x60 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35854 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehashThe rehash delayed work migrates filters from one region to anotheraccording to the number of available credits.The migrated from region is destroyed at the end of the work if thenumber of credits is non-negative as the assumption is that this isindicative of migration being complete. This assumption is incorrect asa non-negative number of credits can also be the result of a failedmigration.The destruction of a region that still has filters referencing it canresult in a use-after-free [1].Fix by not destroying the region if migration failed.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G W 6.9.0-rc2-custom-00782-gf2275c2157d8 #5Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70 mlxsw_sp_acl_atcam_entry_del+0x81/0x210 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 174: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 7: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity updateThe rule activity update delayed work periodically traverses the list ofconfigured rules and queries their activity from the device.As part of this task it accesses the entry pointed by 'ventry->entry',but this entry can be changed concurrently by the rehash delayed work,leading to a use-after-free [1].Fix by closing the race and perform the activity query under the'vregion->lock' mutex.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_workCall Trace: dump_stack_lvl+0xc6/0x120 print_report+0xce/0x670 kasan_report+0xd7/0x110 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30 Allocated by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __kmalloc+0x19c/0x360 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30Freed by task 1039: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x14/0x30 kfree+0xc1/0x290 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300 process_one_work+0x8eb/0x19b0 worker_thread+0x6c9/0xf70 kthread+0x2c9/0x3b0 ret_from_fork+0x4d/0x80 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: prevent possible NULL dereferences from icmp_build_probe()First problem is a double call to __in_dev_get_rcu(), becausethe second one could return NULL.if (__in_dev_get_rcu(dev) && __in_dev_get_rcu(dev)->ifa_list)Second problem is a read from dev->ip6_ptr with no NULL check:if (!list_empty(&rcu_dereference(dev->ip6_ptr)->addr_list))Use the correct RCU API to fix these.v2: add missing include

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in cifs_dump_full_key()Skip sessions that are being teared down (status == SES_EXITING) toavoid UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35870 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in smb2_reconnect_server()The UAF bug is due to smb2_reconnect_server() accessing a session thatis already being teared down by another thread that is executing__cifs_put_smb_ses(). This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses->ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses->ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we're still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_reconnect_server() worker a chance to run and then accessing@ses->ipc:kinit ...mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10[disconnect srv]ls /mnt/1 &>/dev/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 <48> 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call Trace: ? die_addr+0x36/0x90 ? exc_general_protection+0x1c1/0x3f0 ? asm_exc_general_protection+0x26/0x30 ? __list_del_entry_valid_or_report+0x33/0xf0 __cifs_put_smb_ses+0x1ae/0x500 [cifs] smb2_reconnect_server+0x4ed/0x710 [cifs] process_one_work+0x205/0x6b0 worker_thread+0x191/0x360 ? __pfx_worker_thread+0x10/0x10 kthread+0xe2/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix GUP-fast succeeding on secretmem foliosfolio_is_secretmem() currently relies on secretmem folios being LRUfolios, to save some cycles.However, folios might reside in a folio batch without the LRU flag set, ortemporarily have their LRU flag cleared. Consequently, the LRU flag isunreliable for this purpose.In particular, this is the case when secretmem_fault() allocates a freshpage and calls filemap_add_folio()->folio_add_lru(). The folio might beadded to the per-cpu folio batch and won't get the LRU flag set until thebatch was drained using e.g., lru_add_drain().Consequently, folio_is_secretmem() might not detect secretmem folios andGUP-fast can succeed in grabbing a secretmem folio, crashing the kernelwhen we would later try reading/writing to the folio, because the foliohas been unmapped from the directmap.Fix it by removing that unreliable check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: fix VM_PAT handling in COW mappingsPAT handling won't do the right thing in COW mappings: the first PTE (or,in fact, all PTEs) can be replaced during write faults to point at anonfolios. Reliably recovering the correct PFN and cachemode usingfollow_phys() from PTEs will not work in COW mappings.Using follow_phys(), we might just get the address+protection of the anonfolio (which is very wrong), or fail on swap/nonswap entries, failingfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() andtrack_pfn_copy(), not properly calling free_pfn_range().In free_pfn_range(), we either wouldn't call memtype_free() or would callit with the wrong range, possibly leaking memory.To fix that, let's update follow_phys() to refuse returning anon folios,and fallback to using the stored PFN inside vma->vm_pgoff for COW mappingsif we run into that.We will now properly handle untrack_pfn() with COW mappings, where wedon't need the cachemode. We'll have to fail fork()->track_pfn_copy() ifthe first page was replaced by an anon folio, though: we'd have to storethe cachemode in the VMA to make this work, likely growing the VMA size.For now, lets keep it simple and let track_pfn_copy() just fail in thatcase: it would have failed in the past with swap/nonswap entries already,and it would have done the wrong thing with anon folios.Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():<--- C reproducer ---> #include #include #include #include int main(void) { struct io_uring_params p = {}; int ring_fd; size_t size; char *map; ring_fd = io_uring_setup(1, &p); if (ring_fd < 0) { perror("io_uring_setup"); return 1; } size = p.sq_off.array + p.sq_entries * sizeof(unsigned); /* Map the submission queue ring MAP_PRIVATE */ map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, ring_fd, IORING_OFF_SQ_RING); if (map == MAP_FAILED) { perror("mmap"); return 1; } /* We have at least one page. Let's COW it. */ *map = 0; pause(); return 0; }<--- C reproducer --->On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring[ 301.552930] ------------[ cut here ]------------[ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100[ 301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g[ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1[ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4[ 301.559569] RIP: 0010:untrack_pfn+0xf4/0x100[ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000[ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282[ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047[ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200[ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000[ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000[ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000[ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000[ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0[ 301.565725] PKRU: 55555554[ 301.565944] Call Trace:[ 301.566148] [ 301.566325] ? untrack_pfn+0xf4/0x100[ 301.566618] ? __warn+0x81/0x130[ 301.566876] ? untrack_pfn+0xf4/0x100[ 3---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:of: dynamic: Synchronize of_changeset_destroy() with the devlink removalsIn the following sequence: 1) of_platform_depopulate() 2) of_overlay_remove()During the step 1, devices are destroyed and devlinks are removed.During the step 2, OF nodes are destroyed but__of_changeset_entry_destroy() can raise warnings related to missingof_node_put(): ERROR: memory leak, expected refcount 1 instead of 2 ...Indeed, during the devlink removals performed at step 1, the removalitself releasing the device (and the attached of_node) is done by a jobqueued in a workqueue and so, it is done asynchronously with respect tofunction calls.When the warning is present, of_node_put() will be called but wronglytoo late from the workqueue job.In order to be sure that any ongoing devlink removals are done beforethe of_node destruction, synchronize the of_changeset_destroy() with thedevlink removals.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: do not accept non-tunnel GSO skbs landing in a tunnelWhen rx-udp-gro-forwarding is enabled UDP packets might be GROed whenbeing forwarded. If such packets might land in a tunnel this can causevarious issues and udp_gro_receive makes sure this isn't the case bylooking for a matching socket. This is performed inudp4/6_gro_lookup_skb but only in the current netns. This is an issuewith tunneled packets when the endpoint is in another netns. In suchcases the packets will be GROed at the UDP level, which leads to variousissues later on. The same thing can happen with rx-gro-list.We saw this with geneve packets being GROed at the UDP level. In suchcase gso_size is set; later the packet goes through the geneve rx path,the geneve header is pulled, the offset are adjusted and frag_list skbsare not adjusted with regard to geneve. When those skbs hitskb_fragment, it will misbehave. Different outcomes are possibledepending on what the GROed skbs look like; from corrupted packets tokernel crashes.One example is a BUG_ON[1] triggered in skb_segment while processing thefrag_list. Because gso_size is wrong (geneve header was pulled)skb_segment thinks there is "geneve header size" of data in frag_list,although it's in fact the next packet. The BUG_ON itself has nothing todo with the issue. This is only one of the potential issues.Looking up for a matching socket in udp_gro_receive is fragile: thelookup could be extended to all netns (not speaking about performances)but nothing prevents those packets from being modified in between and wecould still not find a matching socket. It's OK to keep the currentlogic there as it should cover most cases but we also need to make surewe handle tunnel packets being GROed too early.This is done by extending the checks in udp_unexpected_gso: GSO packetslacking the SKB_GSO_UDP_TUNNEL/_CSUM bits and landing in a tunnel mustbe segmented.[1] kernel BUG at net/core/skbuff.c:4408! RIP: 0010:skb_segment+0xd2a/0xf70 __udp_gso_segment+0xaa/0x560

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: stop interface during shutdownThe mlxbf_gige driver intermittantly encounters a NULL pointerexception while the system is shutting down via "reboot" command.The mlxbf_driver will experience an exception right after executingits shutdown() method. One example of this exception is:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000[0000000000000070] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] SMPCPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S OE 5.15.0-bf.6.gef6992a #1Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]sp : ffff8000080d3c10x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffffx17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000Call trace: mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige] mlxbf_gige_poll+0x54/0x160 [mlxbf_gige] __napi_poll+0x40/0x1c8 net_rx_action+0x314/0x3a0 __do_softirq+0x128/0x334 run_ksoftirqd+0x54/0x6c smpboot_thread_fn+0x14c/0x190 kthread+0x10c/0x110 ret_from_fork+0x10/0x20Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)---[ end trace 7cc3941aa0d8e6a4 ]---Kernel panic - not syncing: Oops: Fatal exception in interruptKernel Offset: 0x4ce722520000 from 0xffff800008000000PHYS_OFFSET: 0x80000000CPU features: 0x000005c1,a3330e5aMemory Limit: none---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---During system shutdown, the mlxbf_gige driver's shutdown() is always executed.However, the driver's stop() method will only execute if networking interfaceconfiguration logic within the Linux distribution has been setup to do so.If shutdown() executes but stop() does not execute, NAPI remains enabledand this can lead to an exception if NAPI is scheduled while the hardwareinterface has only been partially deinitialized.The networking interface managed by the mlxbf_gige driver must be properlystopped during system shutdown so that IFF_UP is cleared, the hardwareinterface is put into a clean state, and NAPI is fully deinitialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35887 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis shown below: (Thread 1) | (Thread 2) | ax25_ds_timeout()ax25_dev_device_down() | ax25_ds_del_timer() | del_timer() | ax25_dev_put() //FREE | | ax25_dev-> //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erspan: make sure erspan_base_hdr is present in skb->headsyzbot reported a problem in ip6erspan_rcv() [1]Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer makesure erspan_base_hdr is present in skb linear part (skb->head)before getting @ver field from it.Add the missing pskb_may_pull() calls.v2: Reload iph pointer in erspan_rcv() after pskb_may_pull() because skb->head might have changed.[1] BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 pskb_may_pull_reason include/linux/skbuff.h:2742 [inline] pskb_may_pull include/linux/skbuff.h:2756 [inline] ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline] gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610 ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:460 [inline] ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:314 [inline] ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5538 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652 netif_receive_skb_internal net/core/dev.c:5738 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5798 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549 tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1525 [inline] tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:2108 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0xb63/0x1520 fs/read_write.c:590 ksys_write+0x20f/0x4c0 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x93/0xe0 fs/read_write.c:652 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35893 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: prevent kernel-infoleaksyzbot found that tcf_skbmod_dump() was copying four bytesfrom kernel stack to user space [1].The issue here is that 'struct tc_skbmod' has a four bytes hole.We need to clear the structure before filling fields.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline] BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] simple_copy_to_iter net/core/datagram.c:532 [inline] __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546 skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline] netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242 __do_sys_recvfrom net/socket.c:2260 [inline] __se_sys_recvfrom net/socket.c:2256 [inline] __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253 netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317 netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351 nlmsg_unicast include/net/netlink.h:1144 [inline] nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610 rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741 rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline] tcf_add_notify net/sched/act_api.c:2048 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559 rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at: __nla_put lib/nlattr.c:1041 [inline] nla_put+0x1c6/0x230 lib/nlattr.c:1099 tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256 tcf_action_dump_old net/sched/act_api.c:1191 [inline] tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227 tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251 tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628 tcf_add_notify_msg net/sched/act_api.c:2023 [inline] tcf_add_notify net/sched/act_api.c:2042 [inline] tcf_action_add net/sched/act_api.c:2071 [inline] tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119 rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlink_rcv_skb+0x375/0x650 net/netlink/af_netli---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35897 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: discard table flag update with pending basechain deletionHook unregistration is deferred to the commit phase, same occurs withhook updates triggered by the table dormant flag. When both commands arecombined, this results in deleting a basechain while leaving its hookstill registered in the core.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()nft_unregister_flowtable_type() within nf_flow_inet_module_exit() canconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().And thhere is not any protection when iterate over nf_tables_flowtableslist in __nft_flowtable_type_get(). Therefore, there is pertentialdata-race of nf_tables_flowtables list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables listin __nft_flowtable_type_get(), and use rcu_read_lock() in the callernft_flowtable_type_get() to protect the entire type query process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: flush pending destroy work before exit_net releaseSimilar to 2c9f0293280e ("netfilter: nf_tables: flush pending destroywork before netlink notifier") to address a race between exit_net andthe destroy workqueue.The trace below shows an element to be released via destroy workqueuewhile exit_net path (triggered via module removal) has already releasedthe set that is used in such transaction.[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables][ 1360.547984] Call Trace:[ 1360.547991] [ 1360.547998] dump_stack_lvl+0x53/0x70[ 1360.548014] print_report+0xc4/0x610[ 1360.548026] ? __virt_addr_valid+0xba/0x160[ 1360.548040] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 1360.548054] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548176] kasan_report+0xae/0xe0[ 1360.548189] ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548312] nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables][ 1360.548447] ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables][ 1360.548577] ? _raw_spin_unlock_irq+0x18/0x30[ 1360.548591] process_one_work+0x2f1/0x670[ 1360.548610] worker_thread+0x4d3/0x760[ 1360.548627] ? __pfx_worker_thread+0x10/0x10[ 1360.548640] kthread+0x16b/0x1b0[ 1360.548653] ? __pfx_kthread+0x10/0x10[ 1360.548665] ret_from_fork+0x2f/0x50[ 1360.548679] ? __pfx_kthread+0x10/0x10[ 1360.548690] ret_from_fork_asm+0x1a/0x30[ 1360.548707] [ 1360.548719] Allocated by task 192061:[ 1360.548726] kasan_save_stack+0x20/0x40[ 1360.548739] kasan_save_track+0x14/0x30[ 1360.548750] __kasan_kmalloc+0x8f/0xa0[ 1360.548760] __kmalloc_node+0x1f1/0x450[ 1360.548771] nf_tables_newset+0x10c7/0x1b50 [nf_tables][ 1360.548883] nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink][ 1360.548909] nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink][ 1360.548927] netlink_unicast+0x367/0x4f0[ 1360.548935] netlink_sendmsg+0x34b/0x610[ 1360.548944] ____sys_sendmsg+0x4d4/0x510[ 1360.548953] ___sys_sendmsg+0xc9/0x120[ 1360.548961] __sys_sendmsg+0xbe/0x140[ 1360.548971] do_syscall_64+0x55/0x120[ 1360.548982] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 1360.548994] Freed by task 192222:[ 1360.548999] kasan_save_stack+0x20/0x40[ 1360.549009] kasan_save_track+0x14/0x30[ 1360.549019] kasan_save_free_info+0x3b/0x60[ 1360.549028] poison_slab_object+0x100/0x180[ 1360.549036] __kasan_slab_free+0x14/0x30[ 1360.549042] kfree+0xb6/0x260[ 1360.549049] __nft_release_table+0x473/0x6a0 [nf_tables][ 1360.549131] nf_tables_exit_net+0x170/0x240 [nf_tables][ 1360.549221] ops_exit_list+0x50/0xa0[ 1360.549229] free_exit_list+0x101/0x140[ 1360.549236] unregister_pernet_operations+0x107/0x160[ 1360.549245] unregister_pernet_subsys+0x1c/0x30[ 1360.549254] nf_tables_module_exit+0x43/0x80 [nf_tables][ 1360.549345] __do_sys_delete_module+0x253/0x370[ 1360.549352] do_syscall_64+0x55/0x120[ 1360.549360] entry_SYSCALL_64_after_hwframe+0x55/0x5d(gdb) list *__nft_release_table+0x4730x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).11349 list_for_each_entry_safe(flowtable, nf, &table->flowtables, list) {11350 list_del(&flowtable->list);11351 nft_use_dec(&table->use);11352 nf_tables_flowtable_destroy(flowtable);11353 }11354 list_for_each_entry_safe(set, ns, &table->sets, list) {11355 list_del(&set->list);11356 nft_use_dec(&table->use);11357 if (set->flags & (NFT_SET_MAP | NFT_SET_OBJECT))11358 nft_map_deactivat---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35900 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: reject new basechain after table flag updateWhen dormant flag is toggled, hooks are disabled in the commit phase byiterating over current chains in table (existing and new).The following configuration allows for an inconsistent state: add table x add chain x y { type filter hook input priority 0; } add table x { flags dormant; } add chain x w { type filter hook input priority 1; }which triggers the following warning when trying to unregister chain wwhich is already unregistered.[ 127.322252] WARNING: CPU: 7 PID: 1211 at net/netfilter/core.c:50 1 __nf_unregister_net_hook+0x21a/0x260[...][ 127.322519] Call Trace:[ 127.322521] [ 127.322524] ? __warn+0x9f/0x1a0[ 127.322531] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322537] ? report_bug+0x1b1/0x1e0[ 127.322545] ? handle_bug+0x3c/0x70[ 127.322552] ? exc_invalid_op+0x17/0x40[ 127.322556] ? asm_exc_invalid_op+0x1a/0x20[ 127.322563] ? kasan_save_free_info+0x3b/0x60[ 127.322570] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322577] ? __nf_unregister_net_hook+0x21a/0x260[ 127.322583] ? __nf_unregister_net_hook+0x6a/0x260[ 127.322590] ? __nf_tables_unregister_hook+0x8a/0xe0 [nf_tables][ 127.322655] nft_table_disable+0x75/0xf0 [nf_tables][ 127.322717] nf_tables_commit+0x2571/0x2620 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxbf_gige: call request_irq() after NAPI initializedThe mlxbf_gige driver encounters a NULL pointer exception inmlxbf_gige_open() when kdump is enabled. The sequence to reproducethe exception is as follows:a) enable kdumpb) trigger kdump via "echo c > /proc/sysrq-trigger"c) kdump kernel executesd) kdump kernel loads mlxbf_gige modulee) the mlxbf_gige module runs its open() as the the "oob_net0" interface is brought upf) mlxbf_gige module will experience an exception during its open(), something like: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000004 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000 [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000086000004 [#1] SMP CPU: 0 PID: 812 Comm: NetworkManager Tainted: G OE 5.15.0-1035-bluefield #37-Ubuntu Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024 pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : __napi_poll+0x40/0x230 sp : ffff800008003e00 x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8 x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000 x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000 x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0 x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398 x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2 x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238 Call trace: 0x0 net_rx_action+0x178/0x360 __do_softirq+0x15c/0x428 __irq_exit_rcu+0xac/0xec irq_exit+0x18/0x2c handle_domain_irq+0x6c/0xa0 gic_handle_irq+0xec/0x1b0 call_on_irq_stack+0x20/0x2c do_interrupt_handler+0x5c/0x70 el1_interrupt+0x30/0x50 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x7c/0x80 __setup_irq+0x4c0/0x950 request_threaded_irq+0xf4/0x1bc mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige] mlxbf_gige_open+0x5c/0x170 [mlxbf_gige] __dev_open+0x100/0x220 __dev_change_flags+0x16c/0x1f0 dev_change_flags+0x2c/0x70 do_setlink+0x220/0xa40 __rtnl_newlink+0x56c/0x8a0 rtnl_newlink+0x58/0x84 rtnetlink_rcv_msg+0x138/0x3c4 netlink_rcv_skb+0x64/0x130 rtnetlink_rcv+0x20/0x30 netlink_unicast+0x2ec/0x360 netlink_sendmsg+0x278/0x490 __sock_sendmsg+0x5c/0x6c ____sys_sendmsg+0x290/0x2d4 ___sys_sendmsg+0x84/0xd0 __sys_sendmsg+0x70/0xd0 __arm64_sys_sendmsg+0x2c/0x40 invoke_syscall+0x78/0x100 el0_svc_common.constprop.0+0x54/0x184 do_el0_svc+0x30/0xac el0_svc+0x48/0x160 el0t_64_sync_handler+0xa4/0x12c el0t_64_sync+0x1a4/0x1a8 Code: bad PC value ---[ end trace 7d1c3f3bf9d81885 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt Kernel Offset: 0x2870a7a00000 from 0xffff800008000000 PHYS_OFFSET: 0x80000000 CPU features: 0x0,000005c1,a3332a5a Memory Limit: none ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---The exception happens because there is a pending RX interrupt before thecall to request_irq(RX IRQ) executes. Then, the RX IRQ handler firesimmediately after this request_irq() completes. The---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe corresponding netns has been dismantled.Fortunately Josef Bacik could trigger the issue more often,and could test a patch I wrote two years ago.When TCP sockets are closed, we call inet_csk_clear_xmit_timers()to 'stop' the timers.inet_csk_clear_xmit_timers() can be called from any context,including when socket lock is held.This is the reason it uses sk_stop_timer(), aka del_timer().This means that ongoing timers might finish much later.For user sockets, this is fine because each running timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare terminated before the kernel socket is released.Modules using kernel sockets close them in their netns exit()handler.Also add sock_not_owned_by_me() helper to get LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e ("net: rds: acquire refcount on TCP sockets")which attempted to solve the issue in rds only.(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)We probably can remove the check_net() tests fromtcp_out_of_resources() and __tcp_close() in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packetsyzbot reported the following uninit-value access issue [1][2]:nci_rx_work() parses and processes received packet. When the payloadlength is zero, each message type handler reads uninitialized payloadand KMSAN detects this issue. The receipt of a packet with a zero-sizepayload is considered unexpected, and therefore, such packets should besilently discarded.This patch resolved this issue by checking payload size before callingeach message type handler codes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbmon: prevent division by zero in fb_videomode_from_videomode()The expression htotal * vtotal can have a zero value onoverflow. It is necessary to prevent division by zero like infb_var_to_videomode().Found by Linux Verification Center (linuxtesting.org) with Svace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy: The PCI error slot reset maybe triggered after inject ue to UMC multi times, this caused system hang. [ 557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume [ 557.373718] [drm] PCIE GART of 512M enabled. [ 557.373722] [drm] PTB located at 0x0000031FED700000 [ 557.373788] [drm] VRAM is lost due to GPU reset! [ 557.373789] [drm] PSP is resuming... [ 557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset [ 557.547067] [drm] PCI error: detected callback, state(1)!! [ 557.547069] [drm] No support for XGMI hive yet... [ 557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter [ 557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations [ 557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered [ 557.610492] [drm] PCI error: slot reset callback!! ... [ 560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded! [ 560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI [ 560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G OE 5.15.0-91-generic #101-Ubuntu [ 560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023 [ 560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu] [ 560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff <48> 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00 [ 560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202 [ 560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0 [ 560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010 [ 560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08 [ 560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000 [ 560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000 [ 560.803889] FS: 0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000 [ 560.812973] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0 [ 560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 [ 560.843444] PKRU: 55555554 [ 560.846480] Call Trace: [ 560.849225] [ 560.851580] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.856488] ? show_trace_log_lvl+0x1d6/0x2ea [ 560.861379] ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.867778] ? show_regs.part.0+0x23/0x29 [ 560.872293] ? __die_body.cold+0x8/0xd [ 560.876502] ? die_addr+0x3e/0x60 [ 560.880238] ? exc_general_protection+0x1c5/0x410 [ 560.885532] ? asm_exc_general_protection+0x27/0x30 [ 560.891025] ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu] [ 560.898323] amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu] [ 560.904520] process_one_work+0x228/0x3d0How: In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35936 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,as it could be caused only by two impossible conditions:- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1- after first successful search, the found_key corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()Subject: [PATCH] drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()If some the pages or sgt allocation failed, we shouldn't release thepages ref we got earlier, otherwise we will end up with unbalancedget/put_pages() calls. We should instead leave everything in placeand let the BO release function deal with extra cleanup when the objectis destroyed, or let the fault handler try again next time it's called.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ast: Fix soft lockupThere is a while-loop in ast_dp_set_on_off() that could lead toinfinite-loop. This is because the register, VGACRI-Dx, checked inthis API is a scratch register actually controlled by a MCU, namedDPMCU, in BMC.These scratch registers are protected by scu-lock. If suc-lock is notoff, DPMCU can not update these registers and then host will have softlockup due to never updated status.DPMCU is used to control DP and relative registers to handshake withhost's VGA driver. Even the most time-consuming task, DP's linktraining, is less than 100ms. 200ms should be enough.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix possible use-after-free issue on kprobe registrationWhen unloading a module, its state is changing MODULE_STATE_LIVE -> MODULE_STATE_GOING -> MODULE_STATE_UNFORMED. Each change will takea time. `is_module_text_address()` and `__module_text_address()`works with MODULE_STATE_LIVE and MODULE_STATE_GOING.If we use `is_module_text_address()` and `__module_text_address()`separately, there is a chance that the first one is succeeded but thenext one is failed because module->state becomes MODULE_STATE_UNFORMEDbetween those operations.In `check_kprobe_address_safe()`, if the second `__module_text_address()`is failed, that is ignored because it expected a kernel_text address.But it may have failed simply because module->state has been changedto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modifynon-exist module text address (use-after-free).To fix this problem, we should not use separated `is_module_text_address()`and `__module_text_address()`, but use only `__module_text_address()`once and do `try_module_get(module)` which is only available withMODULE_STATE_LIVE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix not validating setsockopt user inputsyzbot reported sco_sock_setsockopt() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90net/bluetooth/sco.c:893Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: fix header validation in geneve[6]_xmit_skbsyzbot is able to trigger an uninit-value in geneve_xmit() [1]Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())uses skb_protocol(skb, true), pskb_inet_may_pull() is only usingskb->protocol.If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,pskb_inet_may_pull() does nothing at all.If a vlan tag was provided by the caller (af_packet in the syzbot case),the network header might not point to the correct location, and skblinear part could be smaller than expected.Add skb_vlan_inet_prepare() to perform a complete mac validation.Use this in geneve for the moment, I suspect we need to adopt thismore broadly.v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest - Only call __vlan_get_protocol() for vlan types.v2,v3 - Addressed Sabrina comments on v1 and v2[1]BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 geneve_xmit_skb drivers/net/geneve.c:910 [inline] geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335 dev_queue_xmit include/linux/netdevice.h:3091 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1318 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 packet_alloc_skb net/packet/af_packet.c:2930 [inline] packet_snd net/packet/af_packet.c:3024 [inline] packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35976 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RINGsyzbot reported an illegal copy in xsk_setsockopt() [1]Make sure to validate setsockopt() @optlen parameter.[1] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 copy_from_sockptr_offset include/linux/sockptr.h:49 [inline] copy_from_sockptr include/linux/sockptr.h:55 [inline] xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420 do_sock_setsockopt+0x3af/0x720 net/socket.c:2311 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75RIP: 0033:0x7fb40587de69Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08 Allocated by task 7549: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:370 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387 kasan_kmalloc include/linux/kasan.h:211 [inline] __do_kmalloc_node mm/slub.c:3966 [inline] __kmalloc+0x233/0x4a0 mm/slub.c:3979 kmalloc include/linux/slab.h:632 [inline] __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869 do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293 __sys_setsockopt+0x1ae/0x250 net/socket.c:2334 __do_sys_setsockopt net/socket.c:2343 [inline] __se_sys_setsockopt net/socket.c:2340 [inline] __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8The buggy address is located 1 bytes to the right of allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)The buggy address belongs to the physical page:page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6canon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)page_type: 0xffffffff()raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223 set_page_owner include/linux/page_owner.h:31 [inline] post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533 prep_new_page mm/page_alloc.c:---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In 'hci_req_sync_complete()', always free the previous syncrequest state before assigning reference to a new one.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:raid1: fix use-after-free for original bio in raid1_write_request()r1_bio->bios[] is used to record new bios that will be issued tounderlying disks, however, in raid1_write_request(), r1_bio->bios[]will set to the original bio temporarily. Meanwhile, if blocked rdevis set, free_r1bio() will be called causing that all r1_bio->bios[]to be freed:raid1_write_request() r1_bio = alloc_r1bio(mddev, bio); -> r1_bio->bios[] is NULL for (i = 0; i < disks; i++) -> for each rdev in conf // first rdev is normal r1_bio->bios[0] = bio; -> set to original bio // second rdev is blocked if (test_bit(Blocked, &rdev->flags)) break if (blocked_rdev) free_r1bio() put_all_bios() bio_put(r1_bio->bios[0]) -> original bio is freedTest scripts:mdadm -CR /dev/md0 -l1 -n4 /dev/sd[abcd] --assume-cleanfio -filename=/dev/md0 -ioengine=libaio -rw=write -bs=4k -numjobs=1 \ -iodepth=128 -name=test -direct=1echo blocked > /sys/block/md0/md/rd2/stateTest result:BUG bio-264 (Not tainted): Object already free-----------------------------------------------------------------------------Allocated in mempool_alloc_slab+0x24/0x50 age=1 cpu=1 pid=869 kmem_cache_alloc+0x324/0x480 mempool_alloc_slab+0x24/0x50 mempool_alloc+0x6e/0x220 bio_alloc_bioset+0x1af/0x4d0 blkdev_direct_IO+0x164/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0 io_submit_one+0x5ca/0xb70 __do_sys_io_submit+0x86/0x270 __x64_sys_io_submit+0x22/0x30 do_syscall_64+0xb1/0x210 entry_SYSCALL_64_after_hwframe+0x6c/0x74Freed in mempool_free_slab+0x1f/0x30 age=1 cpu=1 pid=869 kmem_cache_free+0x28c/0x550 mempool_free_slab+0x1f/0x30 mempool_free+0x40/0x100 bio_free+0x59/0x80 bio_put+0xf0/0x220 free_r1bio+0x74/0xb0 raid1_make_request+0xadf/0x1150 md_handle_request+0xc7/0x3b0 md_submit_bio+0x76/0x130 __submit_bio+0xd8/0x1d0 submit_bio_noacct_nocheck+0x1eb/0x5c0 submit_bio_noacct+0x169/0xd40 submit_bio+0xee/0x1d0 blkdev_direct_IO+0x322/0x8a0 blkdev_write_iter+0x309/0x440 aio_write+0x139/0x2f0Since that bios for underlying disks are not allocated yet, fix thisproblem by using mempool_free() directly to free the r1_bio.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon top of batman-adv. In this case, at least 116 byte would be needed.There will just be an endless spam of batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)in the log but the function will never finish. Problem here is that thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.While this should be handled proactively when:* interface with too low MTU is added* VLAN is added* non-purgeable local mac is added* MTU of an attached interface is reduced* fragmentation setting gets disabled (which most likely requires dropping attached interfaces)not all of these scenarios can be prevented because batman-adv is onlyconsuming events without the the possibility to prevent these actions(non-purgable MAC address added, MTU of an attached interface is reduced).It is therefore necessary to also make sure that the code is able to handlealso the situations when there were already incompatible systemconfiguration are present.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways being available. Fix this by always checking the pointer in__i2c_transfer.[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix oops during rmmod on single-CPU platformsDuring the removal of the idxd driver, registered offline callback isinvoked as part of the clean up process. However, on systems with onlyone CPU online, no valid target is available to migrate theperf context, resulting in a kernel oops: BUG: unable to handle page fault for address: 000000000002a2b8 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 1470e1067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57 Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023 RIP: 0010:mutex_lock+0x2e/0x50 ... Call Trace: __die+0x24/0x70 page_fault_oops+0x82/0x160 do_user_addr_fault+0x65/0x6b0 __pfx___rdmsr_safe_on_cpu+0x10/0x10 exc_page_fault+0x7d/0x170 asm_exc_page_fault+0x26/0x30 mutex_lock+0x2e/0x50 mutex_lock+0x1e/0x50 perf_pmu_migrate_context+0x87/0x1f0 perf_event_cpu_offline+0x76/0x90 [idxd] cpuhp_invoke_callback+0xa2/0x4f0 __pfx_perf_event_cpu_offline+0x10/0x10 [idxd] cpuhp_thread_fun+0x98/0x150 smpboot_thread_fn+0x27/0x260 smpboot_thread_fn+0x1af/0x260 __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x103/0x140 __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x50 __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Fix the issue by preventing the migration of the perf context to aninvalid target.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: xilinx_dpdma: Fix lockingThere are several places where either chan->lock or chan->vchan.lock wasnot held. Add appropriate locking. This fixes lockdep warnings like[ 31.077578] ------------[ cut here ]------------[ 31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.077953] Modules linked in:[ 31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98[ 31.078102] Hardware name: xlnx,zynqmp (DT)[ 31.078169] Workqueue: events_unbound deferred_probe_work_func[ 31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0[ 31.078550] sp : ffffffc083bb2e10[ 31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168[ 31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480[ 31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000[ 31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000[ 31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000[ 31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001[ 31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def[ 31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516[ 31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff[ 31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000[ 31.080307] Call trace:[ 31.080340] xilinx_dpdma_chan_queue_transfer+0x274/0x5e0[ 31.080518] xilinx_dpdma_issue_pending+0x11c/0x120[ 31.080595] zynqmp_disp_layer_update+0x180/0x3ac[ 31.080712] zynqmp_dpsub_plane_atomic_update+0x11c/0x21c[ 31.080825] drm_atomic_helper_commit_planes+0x20c/0x684[ 31.080951] drm_atomic_helper_commit_tail+0x5c/0xb0[ 31.081139] commit_tail+0x234/0x294[ 31.081246] drm_atomic_helper_commit+0x1f8/0x210[ 31.081363] drm_atomic_commit+0x100/0x140[ 31.081477] drm_client_modeset_commit_atomic+0x318/0x384[ 31.081634] drm_client_modeset_commit_locked+0x8c/0x24c[ 31.081725] drm_client_modeset_commit+0x34/0x5c[ 31.081812] __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168[ 31.081899] drm_fb_helper_set_par+0x50/0x70[ 31.081971] fbcon_init+0x538/0xc48[ 31.082047] visual_init+0x16c/0x23c[ 31.082207] do_bind_con_driver.isra.0+0x2d0/0x634[ 31.082320] do_take_over_console+0x24c/0x33c[ 31.082429] do_fbcon_takeover+0xbc/0x1b0[ 31.082503] fbcon_fb_registered+0x2d0/0x34c[ 31.082663] register_framebuffer+0x27c/0x38c[ 31.082767] __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c[ 31.082939] drm_fb_helper_initial_config+0x50/0x74[ 31.083012] drm_fbdev_dma_client_hotplug+0xb8/0x108[ 31.083115] drm_client_register+0xa0/0xf4[ 31.083195] drm_fbdev_dma_setup+0xb0/0x1cc[ 31.083293] zynqmp_dpsub_drm_init+0x45c/0x4e0[ 31.083431] zynqmp_dpsub_probe+0x444/0x5e0[ 31.083616] platform_probe+0x8c/0x13c[ 31.083713] really_probe+0x258/0x59c[ 31.083793] __driver_probe_device+0xc4/0x224[ 31.083878] driver_probe_device+0x70/0x1c0[ 31.083961] __device_attach_driver+0x108/0x1e0[ 31.084052] bus_for_each_drv+0x9c/0x100[ 31.084125] __device_attach+0x100/0x298[ 31.084207] device_initial_probe+0x14/0x20[ 31.084292] bus_probe_device+0xd8/0xdc[ 31.084368] deferred_probe_work_func+0x11c/0x180[ 31.084451] process_one_work+0x3ac/0x988[ 31.084643] worker_thread+0x398/0x694[ 31.084752] kthread+0x1bc/0x1c0[ 31.084848] ret_from_fork+0x10/0x20[ 31.084932] irq event stamp: 64549[ 31.084970] hardirqs last enabled at (64548): [] _raw_spin_unlock_irqrestore+0x80/0x90[ 31.085157]---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix missing hugetlb_lock for resv unchargeThere is a recent report on UFFDIO_COPY over hugetlb:https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/350: lockdep_assert_held(&hugetlb_lock);Should be an issue in hugetlb but triggered in an userfault context, whereit goes into the unlikely path where two threads modifying the resv maptogether. Mike has a fix in that path for resv uncharge but it looks likethe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()will update the cgroup pointer, so it requires to be called with the lockheld.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36004 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Do not use WQ_MEM_RECLAIM flag for workqueueIssue reported by customer during SRIOV testing, call trace:When both i40e and the i40iw driver are loaded, a warningin check_flush_dependency is being triggered. This seemsto be because of the i40e driver workqueue is allocated withthe WQ_MEM_RECLAIM flag, and the i40iw one is not.Similar error was encountered on ice too and it was fixed byremoving the flag. Do the same for i40e too.[Feb 9 09:08] ------------[ cut here ]------------[ +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] isflushing !WQ_MEM_RECLAIM infiniband:0x0[ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966check_flush_dependency+0x10b/0x120[ +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seqsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4nls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtrrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdmaintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssifisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermalintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_coreiTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncoreioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ichintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_padxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbedrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intellibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirrordm_region_hash dm_log dm_mod fuse[ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Nottainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1[ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOSSE5C620.86B.02.01.0013.121520200651 12/15/2020[ +0.000001] Workqueue: i40e i40e_service_task [i40e][ +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120[ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 4881 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fdff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90[ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282[ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:0000000000000027[ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:ffff94d47f620bc0[ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:00000000ffff7fff[ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:ffff94c5451ea180[ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:ffff94c5f1330ab0[ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000)knlGS:0000000000000000[ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:00000000007706f0[ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[ +0.000001] PKRU: 55555554[ +0.000001] Call Trace:[ +0.000001] [ +0.000002] ? __warn+0x80/0x130[ +0.000003] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? report_bug+0x195/0x1a0[ +0.000005] ? handle_bug+0x3c/0x70[ +0.000003] ? exc_invalid_op+0x14/0x70[ +0.000002] ? asm_exc_invalid_op+0x16/0x20[ +0.000006] ? check_flush_dependency+0x10b/0x120[ +0.000002] ? check_flush_dependency+0x10b/0x120[ +0.000002] __flush_workqueue+0x126/0x3f0[ +0.000015] ib_cache_cleanup_one+0x1c/0xe0 [ib_core][ +0.000056] __ib_unregister_device+0x6a/0xb0 [ib_core][ +0.000023] ib_unregister_device_and_put+0x34/0x50 [ib_core][ +0.000020] i40iw_close+0x4b/0x90 [irdma][ +0.000022] i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e][ +0.000035] i40e_service_task+0x126/0x190 [i40e][ +0.000024] process_one_work+0x174/0x340[ +0.000003] worker_th---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: honor table dormant flag from netdev release event pathCheck for table dormant flag otherwise netdev release event path triesto unregister an already unregistered hook.[524854.857999] ------------[ cut here ]------------[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260[...][524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365[524854.858869] Workqueue: netns cleanup_net[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00[524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0[524854.859000] Call Trace:[524854.859006] [524854.859013] ? __warn+0x9f/0x1a0[524854.859027] ? __nf_unregister_net_hook+0x21a/0x260[524854.859044] ? report_bug+0x1b1/0x1e0[524854.859060] ? handle_bug+0x3c/0x70[524854.859071] ? exc_invalid_op+0x17/0x40[524854.859083] ? asm_exc_invalid_op+0x1a/0x20[524854.859100] ? __nf_unregister_net_hook+0x6a/0x260[524854.859116] ? __nf_unregister_net_hook+0x21a/0x260[524854.859135] nf_tables_netdev_event+0x337/0x390 [nf_tables][524854.859304] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859461] ? packet_notifier+0xb3/0x360[524854.859476] ? _raw_spin_unlock_irqrestore+0x11/0x40[524854.859489] ? dcbnl_netdevice_event+0x35/0x140[524854.859507] ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables][524854.859661] notifier_call_chain+0x7d/0x140[524854.859677] unregister_netdevice_many_notify+0x5e1/0xae0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free in l2cap_connect()Extend a critical section to prevent chan from early freeing.Also make the l2cap_connect() return type void. Nothing is using thereturned value but it is ugly to return a potentially freed pointer.Making it void will help with backports because earlier kernels did usethe return value. Now the compile will break for kernels where thispatch is not a complete fix.Call stack summary:[use]l2cap_bredr_sig_cmd l2cap_connect mutex_lock(&conn->chan_lock); | chan = pchan->ops->new_connection(pchan); <- alloc chan | __l2cap_chan_add(conn, chan); | l2cap_chan_hold(chan); | list_add(&chan->list, &conn->chan_l); ... (1) mutex_unlock(&conn->chan_lock); chan->conf_state ... (4) <- use after free[free]l2cap_conn_del mutex_lock(&conn->chan_lock);| foreach chan in conn->chan_l: ... (2)| l2cap_chan_put(chan);| l2cap_chan_destroy| kfree(chan) ... (3) <- chan freed mutex_unlock(&conn->chan_lock);==================================================================BUG: KASAN: slab-use-after-free in instrument_atomic_readinclude/linux/instrumented.h:68 [inline]BUG: KASAN: slab-use-after-free in _test_bitinclude/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: slab-use-after-free in l2cap_connect+0xa67/0x11a0net/bluetooth/l2cap_core.c:4260Read of size 8 at addr ffff88810bf040a0 by task kworker/u3:1/311

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/arm/malidp: fix a possible null pointer dereferenceIn malidp_mw_connector_reset, new memory is allocated with kzalloc, butno check is performed. In order to prevent null pointer dereferencing,ensure that mw_state is checked before calling__drm_atomic_helper_connector_reset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36270 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: tproxy: bail out if IP has been disabled on the devicesyzbot reports:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f][..]RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62Call Trace: nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline] nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168__in_dev_get_rcu() can return NULL, so check for this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36476 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs: Ensure 'ib_sge list' is accessibleMove the declaration of the 'ib_sge list' variable outside the'always_invalidate' block to ensure it remains accessible for usethroughout the function.Previously, 'ib_sge list' was declared within the 'always_invalidate'block, limiting its accessibility, then caused a'BUG: kernel NULL pointer dereference'[1]. ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2d0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? memcpy_orig+0xd5/0x140 rxe_mr_copy+0x1c3/0x200 [rdma_rxe] ? rxe_pool_get_index+0x4b/0x80 [rdma_rxe] copy_data+0xa5/0x230 [rdma_rxe] rxe_requester+0xd9b/0xf70 [rdma_rxe] ? finish_task_switch.isra.0+0x99/0x2e0 rxe_sender+0x13/0x40 [rdma_rxe] do_task+0x68/0x1e0 [rdma_rxe] process_one_work+0x177/0x330 worker_thread+0x252/0x390 ? __pfx_worker_thread+0x10/0x10This change ensures the variable is available for subsequent operationsthat require it.[1] https://lore.kernel.org/linux-rdma/6a1f3e8f-deb0-49f9-bc69-a9b03ecfcda7@fujitsu.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36479 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: bridge: add owner module and take its refcountThe current implementation of the fpga bridge assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the bridge ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_bridgestruct and use it to take the module's refcount. Modify the function forregistering a bridge to take an additional owner module parameter andrename it to avoid conflicts. Use the old function name for a helper macrothat automatically sets the module that registers the bridge as the owner.This ensures compatibility with existing low-level control modules andreduces the chances of registering a bridge without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga bridge.Other changes: opportunistically move put_device() from __fpga_bridge_get()to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity sincethe bridge device is taken in these functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()syzbot is able to trigger the following crash [1],caused by unsafe ip6_dst_idev() use.Indeed ip6_dst_idev() can return NULL, and must always be checked.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline] RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267Code: 02 00 00 49 8d 9f d8 00 00 00 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 f9 32 bf f7 48 8b 1b 48 89 d8 48 c1 e8 03 <42> 80 3c 20 00 74 08 48 89 df e8 e0 32 bf f7 4c 8b 03 48 89 ef 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS: 00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317 fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108 ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline] ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649 ip6_route_output include/net/ip6_route.h:93 [inline] ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120 ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250 sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326 sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455 sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662 sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099 __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197 sctp_connect net/sctp/socket.c:4819 [inline] sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834 __sys_connect_file net/socket.c:2048 [inline] __sys_connect+0x2df/0x310 net/socket.c:2065 __do_sys_connect net/socket.c:2075 [inline] __se_sys_connect net/socket.c:2072 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2072 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36908 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if 'active_list' is empty, whichis intended to confirm iocg is active when it has debt. However, warncan be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()is run at that time: WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190 Call trace: iocg_pay_debt+0x14c/0x190 iocg_kick_waitq+0x438/0x4c0 iocg_waitq_timer_fn+0xd8/0x130 __run_hrtimer+0x144/0x45c __hrtimer_run_queues+0x16c/0x244 hrtimer_interrupt+0x2cc/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the 'active_list' is irrelevant, and 'waitq_timer'is canceled after removing 'active_list' in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Don't free ring buffers that couldn't be re-encryptedIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.The VMBus ring buffer code could free decrypted/shared pages ifset_memory_decrypted() fails. Check the decrypted field in the structvmbus_gpadl for the ring buffers to decide whether to free the memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: vmbus: Track decrypted status in vmbus_gpadlIn CoCo VMs it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.In order to make sure callers of vmbus_establish_gpadl() andvmbus_teardown_gpadl() don't return decrypted/shared pages toallocators, add a field in struct vmbus_gpadl to keep track of thedecryption status of the buffers. This will allow the callers toknow if they should free or leak the pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip on writeback when it's not applicable[WHY]dynamic memory safety error detector (KASAN) catches and generates errormessages "BUG: KASAN: slab-out-of-bounds" as writeback connector does notsupport certain features which are not initialized.[HOW]Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of 'start + len' in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don't free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Reapply "drm/qxl: simplify qxl_fence_wait"This reverts commit 07ed11afb68d94eadd4ffc082b97c2331307c5ea.Stephen Rostedt reports: "I went to run my tests on my VMs and the tests hung on boot up. Unfortunately, the most I ever got out was: [ 93.607888] Testing event system initcall: OK [ 93.667730] Running tests on all trace events: [ 93.669757] Testing all events: OK [ 95.631064] ------------[ cut here ]------------ Timed out after 60 seconds"and further debugging points to a possible circular locking dependencybetween the console_owner locking and the worker pool locking.Reverting the commit allows Steve's VM to boot to completion again.[ This may obviously result in the "[TTM] Buffer eviction failed" messages again, which was the reason for that original revert. But at this point this seems preferable to a non-booting system... ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phonet: fix rtm_phonet_notify() skb allocationfill_route() stores three components in the skb:- struct rtmsg- RTA_DST (u8)- RTA_OIF (u32)Therefore, rtm_phonet_notify() should useNLMSG_ALIGN(sizeof(struct rtmsg)) +nla_total_size(1) +nla_total_size(4)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KEYS: trusted: Fix memory leak in tpm2_key_encode()'scratch' is never freed. Fix this by calling kfree() in the success, andin the error case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()l2cap_le_flowctl_init() can cause both div-by-zero and an integeroverflow since hdev->le_mtu may not fall in the valid range.Move MTU from hci_dev to hci_conn to validate MTU and stop the connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G W 6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 <66> f7 f3 89 c3 ff c3 4d 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS: 0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call Trace: l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline] l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline] l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline] l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline] hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176 process_one_work kernel/workqueue.c:3254 [inline] process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335 worker_thread+0x926/0xe70 kernel/workqueue.c:3416 kthread+0x2e3/0x380 kernel/kthread.c:388 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Modules linked in:---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix division by zero in setup_dsc_configWhen slice_height is 0, the division by slice_height in the calculationof the number of slices will cause a division by zero driver crash. Thisleaves the kernel in a state that requires a reboot. This patch adds acheck to avoid the division by zero.The stack trace below is for the 6.8.4 Kernel. I reproduced the issue ona Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitorconnected via Thunderbolt. The amdgpu driver crashed with this exceptionwhen I rebooted the system with the monitor connected.kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpukernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpuAfter applying this patch, the driver no longer crashes when the monitoris connected and the system is rebooted. I believe this is the sameissue reported for 3113.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37021 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fpga: manager: add owner module and take its refcountThe current implementation of the fpga manager assumes that the low-levelmodule registers a driver for the parent device and uses its owner pointerto take the module's refcount. This approach is problematic since it canlead to a null pointer dereference while attempting to get the manager ifthe parent device does not have a driver.To address this problem, add a module owner pointer to the fpga_managerstruct and use it to take the module's refcount. Modify the functions forregistering the manager to take an additional owner module parameter andrename them to avoid conflicts. Use the old function names for helpermacros that automatically set the module that registers the manager as theowner. This ensures compatibility with existing low-level control modulesand reduces the chances of registering a manager without setting the owner.Also, update the documentation to keep it consistent with the new interfacefor registering an fpga manager.Other changes: opportunistically move put_device() from __fpga_mgr_get() tofpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since themanager device is taken in these functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() isassigned to mhdp_state->current_mode, and there is a dereference of it indrm_mode_set_name(), which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate().Fix this bug add a check of mhdp_state->current_mode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38549 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add 0 size check to mtk_drm_gem_objAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM objectof 0 bytes. Currently, no such check exists and the kernel will panic ifa userspace application attempts to allocate a 0x0 GBM buffer.Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 andverifying that we now return EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38556 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Add a timeout to acquire the command queue semaphorePrevent forced completion handling on an entry that has not yet beenassigned an index, causing an out of bounds access on idx = -22.Instead of waiting indefinitely for the sem, blocking flow now waits forindex to be allocated or a sem acquisition timeout before beginning thetimer for FW completion.Kernel log example:mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38573 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cppc_cpufreq: Fix possible null pointer dereferencecppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called fromdifferent places with various parameters. So cpufreq_cpu_get() can returnnull as 'policy' in some circumstances.Fix this bug by adding null return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38586 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: Fix possible ring buffer corruption on fragmented Tx packets.An issue was found on the RTL8125b when transmitting small fragmentedpackets, whereby invalid entries were inserted into the transmit ringbuffer, subsequently leading to calls to dma_unmap_single() with a nulladdress.This was caused by rtl8169_start_xmit() not noticing changes to nr_fragswhich may occur when small packets are padded (to work around hardwarequirks) in rtl8169_tso_csum_v2().To fix this, postpone inspecting nr_frags until after any padding has beenapplied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38588 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix possible use-after-free issue in ftrace_location()KASAN reports a bug: BUG: KASAN: use-after-free in ftrace_location+0x90/0x120 Read of size 8 at addr ffff888141d40010 by task insmod/424 CPU: 8 PID: 424 Comm: insmod Tainted: G W 6.9.0-rc2+ [...] Call Trace: dump_stack_lvl+0x68/0xa0 print_report+0xcf/0x610 kasan_report+0xb5/0xe0 ftrace_location+0x90/0x120 register_kprobe+0x14b/0xa40 kprobe_init+0x2d/0xff0 [kprobe_example] do_one_initcall+0x8f/0x2d0 do_init_module+0x13a/0x3c0 load_module+0x3082/0x33d0 init_module_from_file+0xd2/0x130 __x64_sys_finit_module+0x306/0x440 do_syscall_64+0x68/0x140 entry_SYSCALL_64_after_hwframe+0x71/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding module is being deleted: CPU1 | CPU2 register_kprobes() { | delete_module() { check_kprobe_address_safe() { | arch_check_ftrace_location() { | ftrace_location() { | lookup_rec() // USE! | ftrace_release_mod() // Free!To fix this issue: 1. Hold rcu lock as accessing ftrace pages in ftrace_location_range(); 2. Use ftrace_location_range() instead of lookup_rec() in ftrace_location(); 3. Call synchronize_rcu() before freeing any ftrace pages both in ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: fix possible dead-lock in nr_rt_ioctl()syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)[1]WARNING: possible circular locking dependency detected6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted------------------------------------------------------syz-executor350/5129 is trying to acquire lock: ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline] ffff8880186e2070 (&nr_node->node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697but task is already holding lock: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #1 (nr_node_list_lock){+...}-{2:2}: lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_remove_node net/netrom/nr_route.c:299 [inline] nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355 nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f-> #0 (&nr_node->node_lock){+...}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [inline] check_prevs_add kernel/locking/lockdep.c:3253 [inline] validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline] _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:356 [inline] nr_node_lock include/net/netrom.h:152 [inline] nr_dec_obs net/netrom/nr_route.c:464 [inline] nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697 sock_do_ioctl+0x158/0x460 net/socket.c:1222 sock_ioctl+0x629/0x8e0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fother info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nr_node_list_lock); lock(&nr_node->node_lock); lock(nr_node_list_lock); lock(&nr_node->node_lock); *** DEADLOCK ***1 lock held by syz-executor350/5129: #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline] #0: ffffffff8f70---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38619 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member "uzonesize" of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member "media_initialized" to struct alauda_info.- Change a condition in alauda_check_media() to ensure the first initialization.- Add an error check for the return value of alauda_init_media().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38621 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: stk1160: fix bounds checking in stk1160_copy_video()The subtract in this condition is reversed. The ->length is the lengthof the buffer. The ->bytesused is how many bytes we have copied thusfar. When the condition is reversed that means the result of thesubtraction is always negative but since it's unsigned then the resultis a very high positive value. That means the overflow check is nevertrue.Additionally, the ->bytesused doesn't actually work for this purposebecause we're not writing to "buf->mem + buf->bytesused". Instead, themath to calculate the destination where we are writing is a bitinvolved. You calculate the number of full lines already written,multiply by two, skip a line if necessary so that we start on an oddnumbered line, and add the offset into the line.To fix this buffer overflow, just take the actual destination where weare writing, if the offset is already out of bounds print an error andreturn. Otherwise, write up to buf->length bytes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38627 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:stm class: Fix a double free in stm_register_device()The put_device(&stm->dev) call will trigger stm_device_release() whichfrees "stm" so the vfree(stm) on the next line is a double free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn't update the respective globalvariable and after insmod - rmmod - insmod cycle the kerneloopses: max3100 spi-PRP0001:01: max3100_probe: adding port 0 BUG: kernel NULL pointer dereference, address: 0000000000000408 ... RIP: 0010:serial_core_register_port+0xa0/0x840 ... max3100_probe+0x1b6/0x280 [max3100] spi_probe+0x8d/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Lock port->lock when calling uart_handle_cts_change()uart_handle_cts_change() has to be called with port lock taken,Since we run it in a separate work, the lock may not be taken atthe time of running. Make sure that it's taken by explicitly doingthat. Without it we got a splat: WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0 ... Workqueue: max3100-0 max3100_work [max3100] RIP: 0010:uart_handle_cts_change+0xa6/0xb0 ... max3100_handlerx+0xc5/0x110 [max3100] max3100_work+0x12a/0x340 [max3100]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: cadence: fix invalid PDI offsetFor some reason, we add an offset to the PDI, presumably to skip thePDI0 and PDI1 which are reserved for BPT.This code is however completely wrong and leads to an out-of-boundsaccess. We were just lucky so far since we used only a couple of PDIsand remained within the PDI array bounds.A Fixes: tag is not provided since there are no known platforms wherethe out-of-bounds would be accessed, and the initial code had problemsas well.A follow-up patch completely removes this useless offset.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38661 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ap: Fix crash in AP internal function modify_bitmap()A system crash like this Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403 Fault in home space mode while using kernel ASCE. AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d Oops: 0038 ilc:3 [#1] PREEMPT SMP Modules linked in: mlx5_ib ... CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8 Hardware name: IBM 3931 A01 704 (LPAR) Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3 000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0 000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff 000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8 Krnl Code: 0000014b75e7b5fc: a7840047 brc 8,0000014b75e7b68a 0000014b75e7b600: 18b2 lr %r11,%r2 #0000014b75e7b602: a7f4000a brc 15,0000014b75e7b616 >0000014b75e7b606: eb22d00000e6 laog %r2,%r2,0(%r13) 0000014b75e7b60c: a7680001 lhi %r6,1 0000014b75e7b610: 187b lr %r7,%r11 0000014b75e7b612: 84960021 brxh %r9,%r6,0000014b75e7b654 0000014b75e7b616: 18e9 lr %r14,%r9 Call Trace: [<0000014b75e7b606>] ap_parse_bitmap_str+0x10e/0x1f8 ([<0000014b75e7b5dc>] ap_parse_bitmap_str+0xe4/0x1f8) [<0000014b75e7b758>] apmask_store+0x68/0x140 [<0000014b75679196>] kernfs_fop_write_iter+0x14e/0x1e8 [<0000014b75598524>] vfs_write+0x1b4/0x448 [<0000014b7559894c>] ksys_write+0x74/0x100 [<0000014b7618a440>] __do_syscall+0x268/0x328 [<0000014b761a3558>] system_call+0x70/0x98 INFO: lockdep is turned off. Last Breaking-Event-Address: [<0000014b75e7b636>] ap_parse_bitmap_str+0x13e/0x1f8 Kernel panic - not syncing: Fatal exception: panic_on_oopsoccured when /sys/bus/ap/a[pq]mask was updated with a relative mask value(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.The fix is simple: use unsigned long values for the internal variables. Thecorrect checks are already in place in the function but a simple int forthe internal variables was used with the possibility to overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don't enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ("dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context") by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39488 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRYWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytesto bug_table entries, and as a result the last entry in a bug table willbe ignored, potentially leading to an unexpected panic(). All priorentries in the table will be handled correctly.The arm64 ABI requires that struct fields of up to 8 bytes arenaturally-aligned, with padding added within a struct such that structare suitably aligned within arrays.When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes signed int file_disp; // 4 bytes unsigned short line; // 2 bytes unsigned short flags; // 2 bytes }... with 12 bytes total, requiring 4-byte alignment.When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is: struct bug_entry { signed int bug_addr_disp; // 4 bytes unsigned short flags; // 2 bytes < implicit padding > // 2 bytes }... with 8 bytes total, with 6 bytes of data and 2 bytes of trailingpadding, requiring 4-byte alginment.When we create a bug_entry in assembly, we align the start of the entryto 4 bytes, which implicitly handles padding for any prior entries.However, we do not align the end of the entry, and so whenCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing paddingbytes.For the main kernel image this is not a problem as find_bug() doesn'tdepend on the trailing padding bytes when searching for entries: for (bug = __start___bug_table; bug < __stop___bug_table; ++bug) if (bugaddr == bug_addr(bug)) return bug;However for modules, module_bug_finalize() depends on the trailingbytes when calculating the number of entries: mod->num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);... and as the last bug_entry lacks the necessary padding bytes, this entrywill not be counted, e.g. in the case of a single entry: sechdrs[i].sh_size == 6 sizeof(struct bug_entry) == 8; sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;Consequently module_find_bug() will miss the last bug_entry when it does: for (i = 0; i < mod->num_bugs; ++i, ++bug) if (bugaddr == bug_addr(bug)) goto out;... which can lead to a kenrel panic due to an unhandled bug.This can be demonstrated with the following module: static int __init buginit(void) { WARN(1, "hello\n"); return 0; } static void __exit bugexit(void) { } module_init(buginit); module_exit(bugexit); MODULE_LICENSE("GPL");... which will trigger a kernel panic when loaded: ------------[ cut here ]------------ hello Unexpected kernel BRK exception at EL1 Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: hello(O+) CPU: 0 PID: 50 Comm: insmod Tainted: G O 6.9.1 #8 Hardware name: linux,dummy-virt (DT) pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : buginit+0x18/0x1000 [hello] lr : buginit+0x18/0x1000 [hello] sp : ffff800080533ae0 x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000 x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58 x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0 x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006 x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720 x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312 x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8 x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000 x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0 Call trace: buginit+0x18/0x1000 [hello] do_one_initcall+0x80/0x1c8 do_init_module+0x60/0x218 load_module+0x1ba4/0x1d70 __do_sys_init_module+0x198/0x1d0 __arm64_sys_init_module+0x1c/0x28 invoke_syscall+0x48/0x114 el0_svc---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39499 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vmci: prevent speculation leaks by sanitizing event in event_deliver()Coverity spotted that event_msg is controlled by user-space,event_msg->event_data.event is passed to event_deliver() and usedas an index without sanitization.This change ensures that the event index is sanitized to mitigate anypossibility of speculative information leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.Only compile tested, no access to HW.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39506 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetIn lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value,but then it is unconditionally passed to skb_add_rx_frag() which looksstrange and could lead to null pointer dereference.lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)In this path there is no code which sets pg_info->page to NULL.So this check looks unneeded and doesn't solve potential problem.But I guess the author had reason to add a check and I have no such cardand can't do real test.In addition, the code in the function liquidio_push_packet() inliquidio/lio_core.c does exactly the same.Based on this, I consider the most acceptable compromise solution toadjust this issue by moving skb_add_rx_frag() into conditional scope.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: remove unnecessary WARN_ON() in implement()Syzkaller hit a warning [1] in a call to implement() when tryingto write a value into a field of smaller size in an output report.Since implement() already has a warn message printed out with thehelp of hid_warn() and value in question gets trimmed with: ... value &= m; ...WARN_ON may be considered superfluous. Remove it to suppress futuresyzkaller triggers.[1]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863Modules linked in:CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863...Call Trace: __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline] usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:904 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40904 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesThe syzbot fuzzer found that the interrupt-URB completion callback inthe cdc-wdm driver was taking too long, and the driver's immediateresubmission of interrupt URBs with -EPROTO status combined with thedummy-hcd emulation to cause a CPU lockup:cdc_wdm 1-1:1.0: nonzero urb status received: -71cdc_wdm 1-1:1.0: wdm_int_callback - 0 byteswatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]CPU#0 Utilization every 4s during lockup: #1: 98% system, 0% softirq, 3% hardirq, 0% idle #2: 98% system, 0% softirq, 3% hardirq, 0% idle #3: 98% system, 0% softirq, 3% hardirq, 0% idle #4: 98% system, 0% softirq, 3% hardirq, 0% idle #5: 98% system, 1% softirq, 3% hardirq, 0% idleModules linked in:irq event stamp: 73096hardirqs last enabled at (73095): [] console_emit_next_record kernel/printk/printk.c:2935 [inline]hardirqs last enabled at (73095): [] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994hardirqs last disabled at (73096): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]hardirqs last disabled at (73096): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551softirqs last enabled at (73048): [] softirq_handle_end kernel/softirq.c:400 [inline]softirqs last enabled at (73048): [] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582softirqs last disabled at (73043): [] __do_softirq+0x14/0x20 kernel/softirq.c:588CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G W 6.10.0-rc2-syzkaller-g8867bbd4a056 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Testing showed that the problem did not occur if the two errormessages -- the first two lines above -- were removed; apparently addingmaterial to the kernel log takes a surprisingly large amount of time.In any case, the best approach for preventing these lockups and toavoid spamming the log with thousands of error messages per second isto ratelimit the two dev_err() calls. Therefore we replace them withdev_err_ratelimited().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible race in __fib6_drop_pcpu_from()syzbot found a race in __fib6_drop_pcpu_from() [1]If compiler reads more than once (*ppcpu_rt),second read could read NULL, if another cpu clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS: 0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline] fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline] fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038 fib6_del_route net/ipv6/ip6_fib.c:1998 [inline] fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043 fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205 fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127 fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175 fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255 __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271 rt6_sync_down_dev net/ipv6/route.c:4906 [inline] rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911 addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855 addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778 notifier_call_chain+0xb9/0x410 kernel/notifier.c:93 call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992 call_netdevice_notifiers_extack net/core/dev.c:2030 [inline] call_netdevice_notifiers net/core/dev.c:2044 [inline] dev_close_many+0x333/0x6a0 net/core/dev.c:1585 unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193 unregister_netdevice_many net/core/dev.c:11276 [inline] default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759 ops_exit_list+0x128/0x180 net/core/net_namespace.c:178 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Lock wiphy in cfg80211_get_stationWiphy should be locked before calling rdev_get_station() (see lockdepassert in ieee80211_get_station()).This fixes the following kernel NULL dereference: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000003001000 [0000000000000050] pgd=0800000002dca003, p4d=0800000002dca003, pud=08000000028e9003, pmd=0000000000000000 Internal error: Oops: 0000000096000006 [#1] SMP Modules linked in: netconsole dwc3_meson_g12a dwc3_of_simple dwc3 ip_gre gre ath10k_pci ath10k_core ath9k ath9k_common ath9k_hw ath CPU: 0 PID: 1091 Comm: kworker/u8:0 Not tainted 6.4.0-02144-g565f9a3a7911-dirty #705 Hardware name: RPT (r1) (DT) Workqueue: bat_events batadv_v_elp_throughput_metric_update pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath10k_sta_statistics+0x10/0x2dc [ath10k_core] lr : sta_set_sinfo+0xcc/0xbd4 sp : ffff000007b43ad0 x29: ffff000007b43ad0 x28: ffff0000071fa900 x27: ffff00000294ca98 x26: ffff000006830880 x25: ffff000006830880 x24: ffff00000294c000 x23: 0000000000000001 x22: ffff000007b43c90 x21: ffff800008898acc x20: ffff00000294c6e8 x19: ffff000007b43c90 x18: 0000000000000000 x17: 445946354d552d78 x16: 62661f7200000000 x15: 57464f445946354d x14: 0000000000000000 x13: 00000000000000e3 x12: d5f0acbcebea978e x11: 00000000000000e3 x10: 000000010048fe41 x9 : 0000000000000000 x8 : ffff000007b43d90 x7 : 000000007a1e2125 x6 : 0000000000000000 x5 : ffff0000024e0900 x4 : ffff800000a0250c x3 : ffff000007b43c90 x2 : ffff00000294ca98 x1 : ffff000006831920 x0 : 0000000000000000 Call trace: ath10k_sta_statistics+0x10/0x2dc [ath10k_core] sta_set_sinfo+0xcc/0xbd4 ieee80211_get_station+0x2c/0x44 cfg80211_get_station+0x80/0x154 batadv_v_elp_get_throughput+0x138/0x1fc batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x1ec/0x414 worker_thread+0x70/0x46c kthread+0xdc/0xe0 ret_from_fork+0x10/0x20 Code: a9bb7bfd 910003fd a90153f3 f9411c40 (f9402814)This happens because STA has time to disconnect and reconnect beforebatadv_v_elp_throughput_metric_update() delayed work gets scheduled. Inthis situation, ath10k_sta_state() can be in the middle of resettingarsta data when the work queue get chance to be scheduled and ends upaccessing it. Locking wiphy prevents that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40912 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()The ieee80211_sta_ps_deliver_wakeup() function takes sta->ps_lock tosynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called fromsoftirq context. However using only spin_lock() to get sta->ps_lock inieee80211_sta_ps_deliver_wakeup() does not prevent softirq to executeon this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try totake this same lock ending in deadlock. Below is an example of rcu stallthat arises in such situation. rcu: INFO: rcu_sched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queued_spin_lock_slowpath+0x58/0x2d0 lr : invoke_tx_handlers_early+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queued_spin_lock_slowpath+0x58/0x2d0 ieee80211_tx+0x80/0x12c ieee80211_tx_pending+0x110/0x278 tasklet_action_common.constprop.0+0x10c/0x144 tasklet_action+0x20/0x28 _stext+0x11c/0x284 ____do_softirq+0xc/0x14 call_on_irq_stack+0x24/0x34 do_softirq_own_stack+0x18/0x20 do_softirq+0x74/0x7c __local_bh_enable_ip+0xa0/0xa4 _ieee80211_wake_txqs+0x3b0/0x4b8 __ieee80211_wake_queue+0x12c/0x168 ieee80211_add_pending_skbs+0xec/0x138 ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480 ieee80211_mps_sta_status_update.part.0+0xd8/0x11c ieee80211_mps_sta_status_update+0x18/0x24 sta_apply_parameters+0x3bc/0x4c0 ieee80211_change_station+0x1b8/0x2dc nl80211_set_station+0x444/0x49c genl_family_rcv_msg_doit.isra.0+0xa4/0xfc genl_rcv_msg+0x1b0/0x244 netlink_rcv_skb+0x38/0x10c genl_rcv+0x34/0x48 netlink_unicast+0x254/0x2bc netlink_sendmsg+0x190/0x3b4 ____sys_sendmsg+0x1e8/0x218 ___sys_sendmsg+0x68/0x8c __sys_sendmsg+0x44/0x84 __arm64_sys_sendmsg+0x20/0x28 do_el0_svc+0x6c/0xe8 el0_svc+0x14/0x48 el0t_64_sync_handler+0xb0/0xb4 el0t_64_sync+0x14c/0x150Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raiseon the same CPU that is holding the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsIn some versions of cfg80211, the ssids poinet might be a valid one eventhough n_ssids is 0. Accessing the pointer in this case will cuase anout-of-bound access. Fix this by checking n_ssids first.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't read past the mfuart notifcationIn case the firmware sends a notification that claims it has more datathan it has, we will read past that was allocated for the notification.Remove the print of the buffer, we won't see it by default. If needed,we can see the content with tracing.This was reported by KFENCE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40942 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: mesh: Fix leak of mesh_preq_queue objectsThe hwmp code use objects of type mesh_preq_queue, added to a list inieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpathgets deleted, ex mesh interface is removed, the entries in that list willnever get cleaned. Fix this by flushing all corresponding items of thepreq_queue in mesh_path_flush_pending().This should take care of KASAN reports like this:unreferenced object 0xffff00000668d800 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419552 (age 1836.444s) hex dump (first 32 bytes): 00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff ..........h..... 8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00 ....>........... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20unreferenced object 0xffff000009051f00 (size 128): comm "kworker/u8:4", pid 67, jiffies 4295419553 (age 1836.440s) hex dump (first 32 bytes): 90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff ..........h..... 36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff 6'.......Xy..... backtrace: [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c [<00000000049bd418>] kmalloc_trace+0x34/0x80 [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8 [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4 [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764 [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4 [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440 [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4 [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508 [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c [<00000000b36425d1>] worker_thread+0x9c/0x634 [<0000000005852dd5>] kthread+0x1bc/0x1c4 [<000000005fccd770>] ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()Use {READ,WRITE}_ONCE() to access kvm->last_boosted_vcpu to ensure theloads and stores are atomic. In the extremely unlikely scenario thecompiler tears the stores, it's theoretically possible for KVM to attemptto get a vCPU using an out-of-bounds index, e.g. if the write is splitinto multiple 8-bit stores, and is paired with a 32-bit load on a VM with257 vCPUs: CPU0 CPU1 last_boosted_vcpu = 0xff; (last_boosted_vcpu = 0x100) last_boosted_vcpu[15:8] = 0x01; i = (last_boosted_vcpu = 0x1ff) last_boosted_vcpu[7:0] = 0x00; vcpu = kvm->vcpu_array[0x1ff];As detected by KCSAN: BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm] write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4: kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:? arch/x86/kvm/vmx/vmx.c:6606) kvm_intel vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890) __x64_sys_ioctl (fs/ioctl.c:890) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x00000012 -> 0x00000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netns: Make get_net_ns() handle zero refcount netSyzkaller hit a warning:refcount_t: addition on 0; use-after-free.WARNING: CPU: 3 PID: 7890 at lib/refcount.c:25 refcount_warn_saturate+0xdf/0x1d0Modules linked in:CPU: 3 PID: 7890 Comm: tun Not tainted 6.10.0-rc3-00100-gcaa4f9578aba-dirty #310Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:refcount_warn_saturate+0xdf/0x1d0Code: 41 49 04 31 ff 89 de e8 9f 1e cd fe 84 db 75 9c e8 76 26 cd fe c6 05 b6 41 49 04 01 90 48 c7 c7 b8 8e 25 86 e8 d2 05 b5 fe 90 <0f> 0b 90 90 e9 79 ff ff ff e8 53 26 cd fe 0f b6 1RSP: 0018:ffff8881067b7da0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c72acRDX: ffff8881026a2140 RSI: ffffffff811c72b5 RDI: 0000000000000001RBP: ffff8881067b7db0 R08: 0000000000000000 R09: 205b5d3730353139R10: 0000000000000000 R11: 205d303938375420 R12: ffff8881086500c4R13: ffff8881086500c4 R14: ffff8881086500b0 R15: ffff888108650040FS: 00007f5b2961a4c0(0000) GS:ffff88823bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055d7ed36fd18 CR3: 00000001482f6000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? show_regs+0xa3/0xc0 ? __warn+0xa5/0x1c0 ? refcount_warn_saturate+0xdf/0x1d0 ? report_bug+0x1fc/0x2d0 ? refcount_warn_saturate+0xdf/0x1d0 ? handle_bug+0xa1/0x110 ? exc_invalid_op+0x3c/0xb0 ? asm_exc_invalid_op+0x1f/0x30 ? __warn_printk+0xcc/0x140 ? __warn_printk+0xd5/0x140 ? refcount_warn_saturate+0xdf/0x1d0 get_net_ns+0xa4/0xc0 ? __pfx_get_net_ns+0x10/0x10 open_related_ns+0x5a/0x130 __tun_chr_ioctl+0x1616/0x2370 ? __sanitizer_cov_trace_switch+0x58/0xa0 ? __sanitizer_cov_trace_const_cmp2+0x1c/0x30 ? __pfx_tun_chr_ioctl+0x10/0x10 tun_chr_ioctl+0x2f/0x40 __x64_sys_ioctl+0x11b/0x160 x64_sys_call+0x1211/0x20d0 do_syscall_64+0x9e/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5b28f165d7Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 8RSP: 002b:00007ffc2b59c5e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5b28f165d7RDX: 0000000000000000 RSI: 00000000000054e3 RDI: 0000000000000003RBP: 00007ffc2b59c650 R08: 00007f5b291ed8c0 R09: 00007f5b2961a4c0R10: 0000000029690010 R11: 0000000000000246 R12: 0000000000400730R13: 00007ffc2b59cf40 R14: 0000000000000000 R15: 0000000000000000 Kernel panic - not syncing: kernel: panic_on_warn set ...This is trigger as below: ns0 ns1tun_set_iff() //dev is tun0 tun->dev = dev//ip link set tun0 netns ns1 put_net() //ref is 0__tun_chr_ioctl() //TUNGETDEVNETNS net = dev_net(tun->dev); open_related_ns(&net->ns, get_net_ns); //ns1 get_net_ns() get_net() //addition on 0Use maybe_get_net() in get_net_ns in case net's ref is zero to fix this

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00RSP: 0018:ffffc90000117378 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline] xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline] xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541 xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835 xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline] xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201 xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline] xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309 ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256 send6+0x611/0xd20 drivers/net/wireguard/socket.c:139 wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178 wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200 wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40 wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Avoid hw_desc array overrun in dw-axi-dmacI have a use case where nr_buffers = 3 and in which each descriptor is composed by 3segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put()handles the hw_desc considering the descs_allocated, this scenario would result in akernel panic (hw_desc array will be overrun).To fix this, the proposal is to add a new member to the axi_dma_desc structure,where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it inaxi_desc_put() to handle the hw_desc array correctly.Additionally I propose to remove the axi_chan_start_first_queued() call after completingthe transfer, since it was identified that unbalance can occur (started descriptors canbe interrupted and transfer ignored due to DMA channel not being enabled).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40982 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: force a dst refcount before doing decryptionAs it says in commit 3bc07321ccc2 ("xfrm: Force a dst refcount beforeentering the xfrm type handlers"):"Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb's destination entry before we enter the xfrm type input/output handlers."On TIPC decryption path it has the same problem, and skb_dst_force()should be called before doing decryption to avoid a possible crash.Shuang reported this issue when this warning is triggered: [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug [] Workqueue: crypto cryptd_queue_worker [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc] [] Call Trace: [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc] [] tipc_rcv+0xcf5/0x1060 [tipc] [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc] [] cryptd_aead_crypt+0xdb/0x190 [] cryptd_queue_worker+0xed/0x190 [] process_one_work+0x93d/0x17e0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40984 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Revert "ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine."Undo the modifications made in commit d410ee5109a1 ("ACPICA: avoid"Info: mapping multiple BARs. Your kernel is fine.""). The initialpurpose of this commit was to stop memory mappings for operationregions from overlapping page boundaries, as it can trigger warningsif different page attributes are present.However, it was found that when this situation arises, mappingcontinues until the boundary's end, but there is still an attempt toread/write the entire length of the map, leading to a NULL pointerdeference. For example, if a four-byte mapping request is made butonly one byte is mapped because it hits the current page boundary'send, a four-byte read/write attempt is still made, resulting in a NULLpointer deference.Instead, map the entire length, as the ACPI specification does notmandate that it must be within the same page boundary. It ispermissible for it to be mapped across different regions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()syzbot found hanging tasks waiting on rtnl_lock [1]A reproducer is available in the syzbot bug.When a request to add multiple actions with the same index is sent, thesecond request will block forever on the first request. This holdsrtnl_lock, and causes tasks to hang.Return -EAGAIN to prevent infinite looping, while keeping documentedbehavior.[1]INFO: task kworker/1:0:5088 blocked for more than 143 seconds.Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000Workqueue: events_power_efficient reg_check_chans_workCall Trace:context_switch kernel/sched/core.c:5409 [inline]__schedule+0xf15/0x5d00 kernel/sched/core.c:6746__schedule_loop kernel/sched/core.c:6823 [inline]schedule+0xe7/0x350 kernel/sched/core.c:6838schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895__mutex_lock_common kernel/locking/mutex.c:684 [inline]__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752wiphy_lock include/net/cfg80211.h:5953 [inline]reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninitialized ratelimit_state->lock access in __ext4_fill_super()In the following concurrency we will access the uninitialized rs->lock:ext4_fill_super ext4_register_sysfs // sysfs registered msg_ratelimit_interval_ms // Other processes modify rs->interval to // non-zero via msg_ratelimit_interval_ms ext4_orphan_cleanup ext4_msg(sb, KERN_INFO, "Errors on filesystem, " __ext4_msg ___ratelimit(&(EXT4_SB(sb)->s_msg_ratelimit_state) if (!rs->interval) // do nothing if interval is 0 return 1; raw_spin_trylock_irqsave(&rs->lock, flags) raw_spin_trylock(lock) _raw_spin_trylock __raw_spin_trylock spin_acquire(&lock->dep_map, 0, 1, _RET_IP_) lock_acquire __lock_acquire register_lock_class assign_lock_key dump_stack(); ratelimit_state_init(&sbi->s_msg_ratelimit_state, 5 * HZ, 10); raw_spin_lock_init(&rs->lock); // init rs->lock hereand get the following dump_stack:=========================================================INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504[...]Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4][...]=========================================================Normally interval is 0 until s_msg_ratelimit_state is initialized, so___ratelimit() does nothing. But registering sysfs precedes initializingrs->lock, so it is possible to change rs->interval to a non-zero valuevia the msg_ratelimit_interval_ms interface of sysfs while rs->lock isuninitialized, and then a call to ext4_msg triggers the problem byaccessing an uninitialized rs->lock. Therefore register sysfs after allinitializations are complete to avoid such problems.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41016 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()xattr in ocfs2 maybe 'non-indexed', which saved with additional spacerequested. It's better to check if the memory is out of bound beforememcmp, although this possibility mainly comes from crafted poisonousimages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41017 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: don't walk off the end of ealistAdd a check before visiting the members of ea tomake sure each ea stays within the ealist.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41027 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features. However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe config not set with this feature. [ 200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660 [ 200.820738] Modules linked in: [ 200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8 [ 200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022 [ 200.885052] RIP: 0010:zap_pte_range+0x43d/0x660

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptorSyzbot has identified a bug in usbcore (see the Closes: tag below)caused by our assumption that the reserved bits in an endpointdescriptor's bEndpointAddress field will always be 0. As a result ofthe bug, the endpoint_is_duplicate() routine in config.c (and possiblyother routines as well) may believe that two descriptors are fordistinct endpoints, even though they have the same direction andendpoint number. This can lead to confusion, including the bugidentified by syzbot (two descriptors with matching endpoint numbersand directions, where one was interrupt and the other was bulk).To fix the bug, we will clear the reserved bits in bEndpointAddresswhen we parse the descriptor. (Note that both the USB-2.0 and USB-3.1specs say these bits are "Reserved, reset to zero".) This requires usto make a copy of the descriptor earlier in usb_parse_endpoint() anduse the copy instead of the original when checking for duplicates.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41056 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Use strnlen() on name fields in V1 wmfw filesUse strnlen() instead of strlen() on the algorithm and coefficient namestring arrays in V1 wmfw files.In V1 wmfw files the name is a NUL-terminated string in a fixed-sizearray. cs_dsp should protect against overrunning the array if the NULterminator is missing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn't mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let's make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: fix possible deadlock in io_register_iowq_max_workers()The io_register_iowq_max_workers() function calls io_put_sq_data(),which acquires the sqd->lock without releasing the uring_lock.Similar to the commit 009ad9f0c6ee ("io_uring: drop ctx->uring_lockbefore acquiring sqd->lock"), this can lead to a potential deadlocksituation.To resolve this issue, the uring_lock is released before callingio_put_sq_data(), and then it is re-acquired after the function call.This change ensures that the locks are acquired in the correctorder, preventing the possibility of a deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: block BH in ila_output()As explained in commit 1378817486d6 ("tipc: block BHbefore using dst_cache"), net/core/dst_cache.chelpers need to be called with BH disabled.ila_output() is called from lwtunnel_output()possibly from process context, and under rcu_read_lock().We might be interrupted by a softirq, re-enter ila_output()and corrupt dst_cache data structures.Fix the race by using local_bh_disable().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41088 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251xfd: fix infinite loop when xmit failsWhen the mcp251xfd_start_xmit() function fails, the driver stopsprocessing messages, and the interrupt routine does not return,running indefinitely even after killing the running application.Error messages:[ 441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16[ 441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).... and repeat forever.The issue can be triggered when multiple devices share the same SPIinterface. And there is concurrent access to the bus.The problem occurs because tx_ring->head increments even ifmcp251xfd_start_xmit() fails. Consequently, the driver skips one TXpackage while still expecting a response inmcp251xfd_handle_tefif_one().Resolve the issue by starting a workqueue to write the tx objsynchronously if err = -EBUSY. In case of another error, decrementtx_ring->head, remove skb from the echo stack, and drop the message.[mkl: use more imperative wording in patch description]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: atm: cxacru: fix endpoint checking in cxacru_bind()Syzbot is still reporting quite an old issue [1] that occurs due toincomplete checking of present usb endpoints. As such, wrongendpoints types may be used at urb sumbitting stage which in turntriggers a warning in usb_submit_urb().Fix the issue by verifying that required endpoint types are presentfor both in and out endpoints, taking into account cmd endpoint type.Unfortunately, this patch has not been tested on real hardware.[1] Syzbot report:usb 1-1: BOGUS urb xfer, pipe 1 != type 3WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502...Call Trace: cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 call_driver_probe drivers/base/dd.c:517 [inline] really_probe+0x23c/0xcd0 drivers/base/dd.c:595 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427 __device_attach+0x228/0x4a0 drivers/base/dd.c:965 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487 device_add+0xc2f/0x2180 drivers/base/core.c:3354 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41149 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid to reuse `hctx` not removed from cpuhp callback listIf the 'hctx' isn't removed from cpuhp callback list, we can't reuse it,otherwise use-after-free may be triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: Fix possible double free in error handling pathWhen auxiliary_device_add() returns error and then callsauxiliary_device_uninit(), callback function adev_releasecalls kfree(madev). We shouldn't call kfree(madev) againin the error handling path. Set 'madev' to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42076 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: can: j1939: Initialize unused data in j1939_send_one()syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()creates full frame including unused data, but it doesn't initializeit. This causes the kernel-infoleak issue. Fix this by initializingunused data.[1]BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 instrument_copy_to_user include/linux/instrumented.h:114 [inline] copy_to_user_iter lib/iov_iter.c:24 [inline] iterate_ubuf include/linux/iov_iter.h:29 [inline] iterate_and_advance2 include/linux/iov_iter.h:245 [inline] iterate_and_advance include/linux/iov_iter.h:271 [inline] _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185 copy_to_iter include/linux/uio.h:196 [inline] memcpy_to_msg include/linux/skbuff.h:4113 [inline] raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x2c4/0x340 net/socket.c:1068 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803 ___sys_recvmsg+0x223/0x840 net/socket.c:2845 do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939 __sys_recvmmsg net/socket.c:3018 [inline] __do_sys_recvmmsg net/socket.c:3041 [inline] __se_sys_recvmmsg net/socket.c:3034 [inline] __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3804 [inline] slab_alloc_node mm/slub.c:3845 [inline] kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577 __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668 alloc_skb include/linux/skbuff.h:1313 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795 sock_alloc_send_skb include/net/sock.h:1842 [inline] j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline] j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline] j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 ____sys_sendmsg+0x877/0xb60 net/socket.c:2584 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638 __sys_sendmsg net/socket.c:2667 [inline] __do_sys_sendmsg net/socket.c:2676 [inline] __se_sys_sendmsg net/socket.c:2674 [inline] __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fBytes 12-15 of 16 are uninitializedMemory access of size 16 starts at ffff888120969690Data copied to user address 00000000200017c0CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/restrack: Fix potential invalid address accessstruct rdma_restrack_entry's kern_name was set to KBUILD_MODNAMEin ib_create_cq(), while if the module exited but forgot del thisrdma_restrack_entry, it would cause a invalid address access inrdma_restrack_clean() when print the owner of this rdma_restrack_entry.These code is used to help find one forgotten PD release in one of theULPs. But it is not needed anymore, so delete them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: Remove WARN() from __xdp_reg_mem_model()syzkaller reports a warning in __xdp_reg_mem_model().The warning occurs only if __mem_id_init_hash_table() returns an error. Itreturns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly.The second case cannot happen since there is a static const rhashtable_paramsstruct with valid fields. So, warning is only triggered when there is aproblem with memory allocation.Thus, there is no sense in using WARN() to handle this error and it can besafely removed.WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75Found by Linux Verification Center (linuxtesting.org) with syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: fsl-asoc-card: set priv->pdev before using itpriv->pdev pointer was set after being used infsl_asoc_card_audmux_init().Move this assignment at the start of the probe function, sosub-functions can correctly use pdev through priv.fsl_asoc_card_audmux_init() dereferences priv->pdev to get access to thedev struct, used with dev_err macros.As priv is zero-initialised, there would be a NULL pointer dereference.Note that if priv->dev is dereferenced before assignment but never used,for example if there is no error to be printed, the driver won't crashprobably due to compiler optimisations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFERIn create_pinctrl(), pinctrl_maps_mutex is acquired before callingadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()calls pinctrl_free(). However, pinctrl_free() attempts to acquirepinctrl_maps_mutex, which is already held by create_pinctrl(), leading toa potential deadlock.This patch resolves the issue by releasing pinctrl_maps_mutex beforecalling pinctrl_free(), preventing the deadlock.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250_omap: Implementation of Errata i2310As per Errata i2310[0], Erroneous timeout can be triggered,if this Erroneous interrupt is not cleared then it may leadsto storm of interrupts, therefore apply Errata i2310 solution.[0] https://www.ti.com/lit/pdf/sprz536 page 23

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42101 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:inet_diag: Initialize pad field in struct inet_diag_req_v2KMSAN reported uninit-value access in raw_lookup() [1]. Diag for rawsockets uses the pad field in struct inet_diag_req_v2 for theunderlying protocol. This field corresponds to the sdiag_raw_protocolfield in struct inet_diag_req_raw.inet_diag_get_exact_compat() converts inet_diag_req toinet_diag_req_v2, but leaves the pad field uninitialized. So the issueoccurs when raw_lookup() accesses the sdiag_raw_protocol field.Fix this by initializing the pad field ininet_diag_get_exact_compat(). Also, do the same fix ininet_diag_dump_compat() to avoid the similar issue in the future.[1]BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_lookup net/ipv4/raw_diag.c:49 [inline] raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was stored to memory at: raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99 inet_diag_cmd_exact+0x7d9/0x980 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline] inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline] netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x332/0x3d0 net/socket.c:745 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639 __sys_sendmsg net/socket.c:2668 [inline] __do_sys_sendmsg net/socket.c:2677 [inline] __se_sys_sendmsg net/socket.c:2675 [inline] __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable req.i created at: inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline] inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42107 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Don't process extts if PTP is disabledThe ice_ptp_extts_event() function can race with ice_ptp_release() andresult in a NULL pointer dereference which leads to a kernel panic.Panic occurs because the ice_ptp_extts_event() function callsptp_clock_event() with a NULL pointer. The ice driver has alreadyreleased the PTP clock by the time the interrupt for the next externaltimestamp event occurs.To fix this, modify the ice_ptp_extts_event() function to check thePTP state and bail early if PTP is not ready.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ntb_netdev: Move ntb_netdev_rx_handler() to call netif_rx() from __netif_rx()The following is emitted when using idxd (DSA) dmanegine as the datamover for ntb_transport that ntb_netdev uses.[74412.546922] BUG: using smp_processor_id() in preemptible [00000000] code: irq/52-idxd-por/14526[74412.556784] caller is netif_rx_internal+0x42/0x130[74412.562282] CPU: 6 PID: 14526 Comm: irq/52-idxd-por Not tainted 6.9.5 #5[74412.569870] Hardware name: Intel Corporation ArcherCity/ArcherCity, BIOS EGSDCRB1.E9I.1752.P05.2402080856 02/08/2024[74412.581699] Call Trace:[74412.584514] [74412.586933] dump_stack_lvl+0x55/0x70[74412.591129] check_preemption_disabled+0xc8/0xf0[74412.596374] netif_rx_internal+0x42/0x130[74412.600957] __netif_rx+0x20/0xd0[74412.604743] ntb_netdev_rx_handler+0x66/0x150 [ntb_netdev][74412.610985] ntb_complete_rxc+0xed/0x140 [ntb_transport][74412.617010] ntb_rx_copy_callback+0x53/0x80 [ntb_transport][74412.623332] idxd_dma_complete_txd+0xe3/0x160 [idxd][74412.628963] idxd_wq_thread+0x1a6/0x2b0 [idxd][74412.634046] irq_thread_fn+0x21/0x60[74412.638134] ? irq_thread+0xa8/0x290[74412.642218] irq_thread+0x1a0/0x290[74412.646212] ? __pfx_irq_thread_fn+0x10/0x10[74412.651071] ? __pfx_irq_thread_dtor+0x10/0x10[74412.656117] ? __pfx_irq_thread+0x10/0x10[74412.660686] kthread+0x100/0x130[74412.664384] ? __pfx_kthread+0x10/0x10[74412.668639] ret_from_fork+0x31/0x50[74412.672716] ? __pfx_kthread+0x10/0x10[74412.676978] ret_from_fork_asm+0x1a/0x30[74412.681457] The cause is due to the idxd driver interrupt completion handler usesthreaded interrupt and the threaded handler is not hard or soft interruptcontext. However __netif_rx() can only be called from interrupt context.Change the call to netif_rx() in order to allow completion via normalcontext for dmaengine drivers that utilize threaded irq handling.While the following commit changed from netif_rx() to __netif_rx(),baebdf48c360 ("net: dev: Makes sure netif_rx() can be invoked in any context."),the change should've been a noop instead. However, the code precedes thisfix should've been using netif_rx_ni() or netif_rx_any_context().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42114 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]Modules linked in:irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check pipe offset before setting vblankpipe_ctx has a size of MAX_PIPES so checking its index before accessingthe array.This fixes an OVERRUN issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check index msg_id before read or write[WHAT]msg_id is used as an array index and it cannot be a negative value, andtherefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).[HOW]Check whether msg_id is valid before reading and setting.This fixes 4 OVERRUN issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL pointer check for kzalloc[Why & How]Check return pointer of kzalloc before using it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Make qedf_execute_tmf() non-preemptibleStop calling smp_processor_id() from preemptible code inqedf_execute_tmf90. This results in BUG_ON() when running an RT kernel.[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42130 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfc/nci: Add the inconsistency check between the input data length and countwrite$nci(r0, &(0x7f0000000740)=ANY=[@ANYBLOB="610501"], 0xf)Syzbot constructed a write() call with a data length of 3 bytes but a count valueof 15, which passed too little data to meet the basic requirements of the functionnci_rf_intf_activated_ntf_packet().Therefore, increasing the comparison between data length and count value to avoidproblems caused by inconsistent data length and count.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42139 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Fix improper extts handlingExtts events are disabled and enabled by the application ts2phc.However, in case where the driver is removed when the application isrunning, a specific extts event remains enabled and can cause a kernelcrash.As a side effect, when the driver is reloaded and application is startedagain, remaining extts event for the channel from a previous run willkeep firing and the message "extts on unexpected channel" might beprinted to the user.To avoid that, extts events shall be disabled when PTP is released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnx2x: Fix multiple UBSAN array-index-out-of-boundsFix UBSAN warnings that occur when using a system with 32 physicalcpu cores or more, or when the user defines a number of Ethernetqueues greater than or equal to FP_SB_MAX_E1x using the num_queuesmodule parameter.Currently there is a read/write out of bounds that occurs on the array"struct stats_query_entry query" present inside the "bnx2x_fw_stats_req"struct in "drivers/net/ethernet/broadcom/bnx2x/bnx2x.h".Looking at the definition of the "struct stats_query_entry query" array:struct stats_query_entry query[FP_SB_MAX_E1x+ BNX2X_FIRST_QUEUE_QUERY_IDX];FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts andhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3meaning the array has a total size of 19.Since accesses to "struct stats_query_entry query" are offset-ted byBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernetqueues should not exceed FP_SB_MAX_E1x (16). However one of these queuesis reserved for FCOE and thus the number of Ethernet queues should be setto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) ifit is not.This is also described in a comment in the source code indrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definitionof FP_SB_MAX_E1x. Below is the part of this explanation that it importantfor this patch/* * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is * control by the number of fast-path status blocks supported by the * device (HW/FW). Each fast-path status block (FP-SB) aka non-default * status block represents an independent interrupts context that can * serve a regular L2 networking queue. However special L2 queues such * as the FCoE queue do not require a FP-SB and other components like * the CNIC may consume FP-SB reducing the number of possible L2 queues * * If the maximum number of FP-SB available is X then: * a. If CNIC is supported it consumes 1 FP-SB thus the max number of * regular L2 queues is Y=X-1 * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor) * c. If the FCoE L2 queue is supported the actual number of L2 queues * is Y+1 * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for * slow-path interrupts) or Y+2 if CNIC is supported (one additional * FP interrupt context for the CNIC). * e. The number of HW context (CID count) is always X or X+1 if FCoE * L2 queue is supported. The cid for the FCoE L2 queue is always X. */However this driver also supports NICs that use the E2 controller which canhandle more queues due to having more FP-SB represented by FP_SB_MAX_E2.Looking at the commits when the E2 support was added, it was originallyusing the E1x parameters: commit f2e0899f0f27 ("bnx2x: Add 57712 support").Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driverwas later updated to take full advantage of the E2 instead of having it belimited to the capabilities of the E1x. But as far as we can tell, thearray "stats_query_entry query" was still limited to using the FP-SBavailable to the E1x cards as part of an oversignt when the driver wasupdated to take full advantage of the E2, and now with the driver beingaware of the greater queue size supported by E2 NICs, it causes the UBSANwarnings seen in the stack traces below.This patch increases the size of the "stats_query_entry query" array byreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handleboth types of NICs.Stack traces:UBSAN: array-index-out-of-bounds in drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11index 20 is out of range for type 'stats_query_entry [19]'CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic #202405052133Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42154 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn't have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of clear-key structures on failureWipe all sensitive data from stack for all IOCTLs, which convert aclear-key into a protected- or secure-key.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe sensitive data on failureWipe sensitive data from stack also if the copy_to_user() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42158 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Use kfree_sensitive() to fix Coccinelle warningsReplace memzero_explicit() and kfree() with kfree_sensitive() to fixwarnings reported by Coccinelle:WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643)WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42162 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv->stats_report->stats array.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42224 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ("net: dsa: mv88e6xxx: Support multiple MDIObusses") mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip->mdios beingempty. However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42228 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually need to have a separate value of 0xffffffff.(Christian)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Validate payload length before processing blockMove the payload length check in cs_dsp_load() and cs_dsp_coeff_load()to be done before the block is processed.The check that the length of a block payload does not exceed the numberof remaining bytes in the firwmware file buffer was being done near theend of the loop iteration. However, some code before that check used thelength field without validating it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Return error if block header overflows fileReturn an error from cs_dsp_power_up() if a block header is longerthan the amount of data left in the file.The previous code in cs_dsp_load() and cs_dsp_load_coeff() would loopwhile there was enough data left in the file for a valid region. Thisprotected against overrunning the end of the file data, but it didn'tabort the file processing with an error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: mos7840: fix crash on resumeSince commit c49cfa917025 ("USB: serial: use generic method if noalternative is provided in usb serial layer"), USB serial core calls thegeneric resume implementation when the driver has not provided one.This can trigger a crash on resume with mos7840 since support formultiple read URBs was added back in 2011. Specifically, both port readURBs are now submitted on resume for open ports, but the context pointerof the second URB is left set to the core rather than mos7840 portstructure.Fix this by implementing dedicated suspend and resume functions formos7840.Tested with Delock 87414 USB 2.0 to 4x serial adapter.[ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42246 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socketWhen using a BPF program on kernel_connect(), the call can return -EPERM. Thiscauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causingthe kernel to potentially freeze up.Neil suggested: This will propagate -EPERM up into other layers which might not be ready to handle it. It might be safer to map EPERM to an error we would be more likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.ECONNREFUSED as error seems reasonable. For programs setting a different errorcan be out of reach (see handling in 4fbac77d2d09) in particular on kernelswhich do not have f10d05966196 ("bpf: Make BPF_PROG_RUN_ARRAY return -errinstead of allow boolean"), thus given that it is better to simply remap forconsistent behavior. UDP does handle EPERM in xs_udp_send_request().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42247 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory location: Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df) Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)Avoid such unaligned memory accesses by instead using theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix a use after free in hfcmulti_tx()Don't dereference *sp after calling dev_kfree_skb(*sp).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42281 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a segment issue when downgrading gso_sizeLinearize the skb when downgrading gso_size because it may trigger aBUG_ON() later when the skb is segmented as described in [1,2].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42283 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nexthop: Initialize all fields in dumped nexthopsstruct nexthop_grp contains two reserved fields that are not initialized bynla_put_nh_group(), and carry garbage. This can be observed e.g. withstrace (edited for clarity): # ip nexthop add id 1 dev lo # ip nexthop add id 101 group 1 # strace -e recvmsg ip nexthop get id 101 ... recvmsg(... [{nla_len=12, nla_type=NHA_GROUP}, [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52The fields are reserved and therefore not currently used. But as they are, theyleak kernel memory, and the fact they are not just zero complicates repurposingof the fields for new ends. Initialize the full structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42284 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows: conn_id->cm_id.iw = cm_id; cm_id->context = conn_id; cm_id->cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42290 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the 'scheduling while atomic' bug in thecontext switch path during device probing: BUG: scheduling while atomic: kworker/u13:1/48/0x00000002 Call trace: __schedule_bug+0x54/0x6c __schedule+0x7f0/0xa94 schedule+0x5c/0xc4 schedule_preempt_disabled+0x24/0x40 __mutex_lock.constprop.0+0x2c0/0x540 __mutex_lock_slowpath+0x14/0x20 mutex_lock+0x48/0x54 clk_prepare_lock+0x44/0xa0 clk_prepare+0x20/0x44 imx_irqsteer_resume+0x28/0xe0 pm_generic_runtime_resume+0x2c/0x44 __genpd_runtime_resume+0x30/0x80 genpd_runtime_resume+0xc8/0x2c0 __rpm_callback+0x48/0x1d8 rpm_callback+0x6c/0x78 rpm_resume+0x490/0x6b4 __pm_runtime_resume+0x50/0x94 irq_chip_pm_get+0x2c/0xa0 __irq_do_set_handler+0x178/0x24c irq_set_chained_handler_and_data+0x60/0xa4 mxc_gpio_probe+0x160/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add a per-VF limit on number of FDIR filtersWhile the iavf driver adds a s/w limit (128) on the number of FDIRfilters that the VF can request, a malicious VF driver can request morethan that and exhaust the resources for other VFs.Add a similar limit in ice.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: handle inconsistent state in nilfs_btnode_create_block()Syzbot reported that a buffer state inconsistency was detected innilfs_btnode_create_block(), triggering a kernel bug.It is not appropriate to treat this inconsistency as a bug; it can occurif the argument block address (the buffer index of the newly createdblock) is a virtual block number and has been reallocated due tocorruption of the bitmap used to manage its allocation state.So, modify nilfs_btnode_create_block() and its callers to treat it as apossible filesystem error, rather than triggering a kernel bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: make sure the first directory block is not a holeThe syzbot constructs a directory that has no dirblock but is non-inline,i.e. the first directory block is a hole. And no errors are reported whencreating files in this directory in the following flow. ext4_mknod ... ext4_add_entry // Read block 0 ext4_read_dirblock(dir, block, DIRENT) bh = ext4_bread(NULL, inode, block, 0) if (!bh && (type == INDEX || type == DIRENT_HTREE)) // The first directory block is a hole // But type == DIRENT, so no error is reported.After that, we get a directory block without '.' and '..' but with a validdentry. This may cause some code that relies on dot or dotdot (such asmake_indexed_dir()) to crash.Therefore when ext4_read_dirblock() finds that the first directory blockis a hole report that the filesystem is corrupted and return an error toavoid loading corrupted data from disk causing something bad.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue. do_split unsigned split dx_make_map count = 1 split = count/2 = 0; continued = hash2 == map[split - 1].hash; ---> map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot's crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows: bus dentry1 hole dentry2 free|xx--|xx-------------|...............|xx-------------|...............|0 12 (8+248)=256 268 256 524 (8+256)=264 788 236 1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That's why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid using corrupted block bitmap bufferWhen the filesystem block bitmap is corrupted, we detect the corruptionwhile loading the bitmap and fail the allocation with error. However thenext allocation from the same bitmap will notice the bitmap buffer isalready loaded and tries to allocate from the bitmap with mixed results(depending on the exact nature of the bitmap corruption). Fix theproblem by using BH_verified bit to indicate whether the bitmap is validor not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42309 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sysctl: always initialize i_uid/i_gidAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()can safely skip setting them.Commit 5ec27ec735ba ("fs/proc/proc_sysctl.c: fix the default values ofi_uid/i_gid on /proc/sys inodes.") added defaults for i_uid/i_gid whenset_ownership() was not implemented. It also missed adjustingnet_ctl_set_ownership() to use the same default values in case thecomputation of a better value failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Don't lose track of restrictions on cred_transferWhen a process' cred struct is replaced, this _almost_ always invokesthe cred_prepare LSM hook; but in one special case (whenKEYCTL_SESSION_TO_PARENT updates the parent's credentials), thecred_transfer LSM hook is used instead. Landlock only implements thecred_prepare hook, not cred_transfer, so KEYCTL_SESSION_TO_PARENT causesall information on Landlock restrictions to be lost.This basically means that a process with the ability to use the fork()and keyctl() syscalls can get rid of all Landlock restrictions onitself.Fix it by adding a cred_transfer hook that does the same thing as theexisting cred_prepare hook. (Implemented by having hook_cred_prepare()call hook_cred_transfer() so that the two functions are less likely toaccidentally diverge in the future.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42321 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: flow_dissector: use DEBUG_NET_WARN_ON_ONCEThe following splat is easy to reproduce upstream as well as in -stablekernels. Florian Westphal provided the following commit: d1dab4f71d37 ("net: add and use __skb_get_hash_symmetric_net")but this complementary fix has been also suggested by Willem de Bruijnand it can be easily backported to -stable kernel which consists inusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splatgiven __skb_get_hash() is used by the nftables tracing infrastructure toto identify packets in traces.[69133.561393] ------------[ cut here ]------------[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/[...][69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ffff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28[69133.562020] FS: 00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000[69133.562027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0[69133.562040] Call Trace:[69133.562044] [69133.562049] ? __warn+0x9f/0x1a0[ 1211.841384] ? __skb_flow_dissect+0x107e/0x2860[...][ 1211.841496] ? bpf_flow_dissect+0x160/0x160[ 1211.841753] __skb_get_hash+0x97/0x280[ 1211.841765] ? __skb_get_hash_symmetric+0x230/0x230[ 1211.841776] ? mod_find+0xbf/0xe0[ 1211.841786] ? get_stack_info_noinstr+0x12/0xe0[ 1211.841798] ? bpf_ksym_find+0x56/0xe0[ 1211.841807] ? __rcu_read_unlock+0x2a/0x70[ 1211.841819] nft_trace_init+0x1b9/0x1c0 [nf_tables][ 1211.841895] ? nft_trace_notify+0x830/0x830 [nf_tables][ 1211.841964] ? get_stack_info+0x2b/0x80[ 1211.841975] ? nft_do_chain_arp+0x80/0x80 [nf_tables][ 1211.842044] nft_do_chain+0x79c/0x850 [nf_tables]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42322 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: properly dereference pe in ip_vs_add_serviceUse pe directly to resolve sparse warning: net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: missing check virtioTwo missing check in virtio_net_hdr_to_skb() allowed syzbotto crash kernels again1. After the skb_segment function the buffer may become non-linear(nr_frags != 0), but since the SKBTX_SHARED_FRAG flag is not set anywherethe __skb_linearize function will not be executed, then the buffer willremain non-linear. Then the condition (offset >= skb_headlen(skb))becomes true, which causes WARN_ON_ONCE in skb_checksum_help.2. The struct sk_buff and struct virtio_net_hdr members must bemathematically related.(gso_size) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) must be greater than (needed) otherwise WARN_ON_ONCE.(remainder) may be 0 if division is without remainder.offset+2 (4191) > skb_headlen() (1116)WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Modules linked in:CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_checksum_help+0x5e2/0x740 net/core/dev.c:3303Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 efRSP: 0018:ffffc90003a9f338 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045cR13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105dFS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ip_do_fragment+0xa1b/0x18b0 net/ipv4/ip_output.c:777 ip_fragment.constprop.0+0x161/0x230 net/ipv4/ip_output.c:584 ip_finish_output_gso net/ipv4/ip_output.c:286 [inline] __ip_finish_output net/ipv4/ip_output.c:308 [inline] __ip_finish_output+0x49c/0x650 net/ipv4/ip_output.c:295 ip_finish_output+0x31/0x310 net/ipv4/ip_output.c:323 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x13b/0x2a0 net/ipv4/ip_output.c:433 dst_output include/net/dst.h:451 [inline] ip_local_out+0xaf/0x1a0 net/ipv4/ip_output.c:129 iptunnel_xmit+0x5b4/0x9b0 net/ipv4/ip_tunnel_core.c:82 ipip6_tunnel_xmit net/ipv6/sit.c:1034 [inline] sit_tunnel_xmit+0xed2/0x28f0 net/ipv6/sit.c:1076 __netdev_start_xmit include/linux/netdevice.h:4940 [inline] netdev_start_xmit include/linux/netdevice.h:4954 [inline] xmit_one net/core/dev.c:3545 [inline] dev_hard_start_xmit+0x13d/0x6d0 net/core/dev.c:3561 __dev_queue_xmit+0x7c1/0x3d60 net/core/dev.c:4346 dev_queue_xmit include/linux/netdevice.h:3134 [inline] packet_xmit+0x257/0x380 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3087 [inline] packet_sendmsg+0x24ca/0x5240 net/packet/af_packet.c:3119 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0xd5/0x180 net/socket.c:745 __sys_sendto+0x255/0x340 net/socket.c:2190 __do_sys_sendto net/socket.c:2202 [inline] __se_sys_sendto net/socket.c:2198 [inline] __x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x40/0x110 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x63/0x6bFound by Linux Verification Center (linuxtesting.org) with Syzkaller

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kvm: s390: Reject memory region operations for ucontrol VMsThis change rejects the KVM_SET_USER_MEMORY_REGION andKVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.This is necessary since ucontrol VMs have kvm->arch.gmap set to 0 andwould thus result in a null pointer dereference further in.Memory management needs to be performed in userspace and using theioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGIONand KVM_SET_USER_MEMORY_REGION2.[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix a possible null pointer dereferenceIn function lpfc_xcvr_data_show, the memory allocation with kmalloc mightfail, thereby making rdp_context a null pointer. In the following contextand functions that use this pointer, there are dereferencing operations,leading to null pointer dereference.To fix this issue, a null pointer check should be added. If it is null,use scnprintf to notify the user and return len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier"flag"), 'epc_features' got dereferenced without the NULL check, leading tothe following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)Thus, remove the redundant NULL check and also use the epc_features::{msix_capable/msi_capable} flags directly to avoid local variables.[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix infinite loop when replaying fast_commitWhen doing fast_commit replay an infinite loop may occur due to anuninitialized extent_status struct. ext4_ext_determine_insert_hole() doesnot detect the replay and calls ext4_es_find_extent_range(), which willreturn immediately without initializing the 'es' variable.Because 'es' contains garbage, an integer overflow may happen causing aninfinite loop in this function, easily reproducible using fstest generic/039.This commit fixes this issue by unconditionally initializing the structurein function ext4_es_find_extent_range().Thanks to Zhang Yi, for figuring out the real problem!

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Handle invalid decoder vsiHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsiis valid for future use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43832 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/uv: Don't call folio_wait_writeback() without a folio referencefolio_wait_writeback() requires that no spinlocks are held and thata folio reference is held, as documented. After we dropped the PTL, thefolio could get freed concurrently. So grab a temporary reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xdp: fix invalid wait context of page_pool_destroy()If the driver uses a page pool, it creates a page pool withpage_pool_create().The reference count of page pool is 1 as default.A page pool will be destroyed only when a reference count reaches 0.page_pool_destroy() is used to destroy page pool, it decreases areference count.When a page pool is destroyed, ->disconnect() is called, which ismem_allocator_disconnect().This function internally acquires mutex_lock().If the driver uses XDP, it registers a memory model withxdp_rxq_info_reg_mem_model().The xdp_rxq_info_reg_mem_model() internally increases a page poolreference count if a memory model is a page pool.Now the reference count is 2.To destroy a page pool, the driver should call both page_pool_destroy()and xdp_unreg_mem_model().The xdp_unreg_mem_model() internally calls page_pool_destroy().Only page_pool_destroy() decreases a reference count.If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), wewill face an invalid wait context warning.Because xdp_unreg_mem_model() calls page_pool_destroy() withrcu_read_lock().The page_pool_destroy() internally acquires mutex_lock().Splat looks like:=============================[ BUG: Invalid wait context ]6.10.0-rc6+ #4 Tainted: G W-----------------------------ethtool/1806 is trying to lock:ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150other info that might help us debug this:context-{5:5}3 locks held by ethtool/1806:stack backtrace:CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fedHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021Call Trace:dump_stack_lvl+0x7e/0xc0__lock_acquire+0x1681/0x4de0? _printk+0x64/0xe0? __pfx_mark_lock.part.0+0x10/0x10? __pfx___lock_acquire+0x10/0x10lock_acquire+0x1b3/0x580? mem_allocator_disconnect+0x73/0x150? __wake_up_klogd.part.0+0x16/0xc0? __pfx_lock_acquire+0x10/0x10? dump_stack_lvl+0x91/0xc0__mutex_lock+0x15c/0x1690? mem_allocator_disconnect+0x73/0x150? __pfx_prb_read_valid+0x10/0x10? mem_allocator_disconnect+0x73/0x150? __pfx_llist_add_batch+0x10/0x10? console_unlock+0x193/0x1b0? lockdep_hardirqs_on+0xbe/0x140? __pfx___mutex_lock+0x10/0x10? tick_nohz_tick_stopped+0x16/0x90? __irq_work_queue_local+0x1e5/0x330? irq_work_queue+0x39/0x50? __wake_up_klogd.part.0+0x79/0xc0? mem_allocator_disconnect+0x73/0x150mem_allocator_disconnect+0x73/0x150? __pfx_mem_allocator_disconnect+0x10/0x10? mark_held_locks+0xa5/0xf0? rcu_is_watching+0x11/0xb0page_pool_release+0x36e/0x6d0page_pool_destroy+0xd7/0x440xdp_unreg_mem_model+0x1a7/0x2a0? __pfx_xdp_unreg_mem_model+0x10/0x10? kfree+0x125/0x370? bnxt_free_ring.isra.0+0x2eb/0x500? bnxt_free_mem+0x5ac/0x2500xdp_rxq_info_unreg+0x4a/0xd0bnxt_free_mem+0x1356/0x2500bnxt_close_nic+0xf0/0x3b0? __pfx_bnxt_close_nic+0x10/0x10? ethnl_parse_bit+0x2c6/0x6d0? __pfx___nla_validate_parse+0x10/0x10? __pfx_ethnl_parse_bit+0x10/0x10bnxt_set_features+0x2a8/0x3e0__netdev_update_features+0x4dc/0x1370? ethnl_parse_bitset+0x4ff/0x750? __pfx_ethnl_parse_bitset+0x10/0x10? __pfx___netdev_update_features+0x10/0x10? mark_held_locks+0xa5/0xf0? _raw_spin_unlock_irqrestore+0x42/0x70? __pm_runtime_resume+0x7d/0x110ethnl_set_features+0x32d/0xa20To fix this problem, it uses rhashtable_lookup_fast() instead ofrhashtable_lookup() with rcu_read_lock().Using xa without rcu_read_lock() here is safe.xa is freed by __xdp_mem_allocator_rcu_free() and this is called bycall_rcu() of mem_xa_remove().The mem_xa_remove() is called by page_pool_destroy() if a referencecount reaches 0.The xa is already protected by the reference count mechanism well in thecontrol plane.So removing rcu_read_lock() for page_pool_destroy() is safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_net: Fix napi_skb_cache_put warningAfter the commit bdacf3e34945 ("net: Use nested-BH locking fornapi_alloc_cache.") was merged, the following warning began to appear: WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napi_skb_cache_put+0x82/0x4b0 __warn+0x12f/0x340 napi_skb_cache_put+0x82/0x4b0 napi_skb_cache_put+0x82/0x4b0 report_bug+0x165/0x370 handle_bug+0x3d/0x80 exc_invalid_op+0x1a/0x50 asm_exc_invalid_op+0x1a/0x20 __free_old_xmit+0x1c8/0x510 napi_skb_cache_put+0x82/0x4b0 __free_old_xmit+0x1c8/0x510 __free_old_xmit+0x1c8/0x510 __pfx___free_old_xmit+0x10/0x10The issue arises because virtio is assuming it's running in NAPI contexteven when it's not, such as in the netpoll case.To resolve this, modify virtnet_poll_tx() to only set NAPI when budgetis available. Same for virtnet_poll_cleantx(), which always assumed thatit was in a NAPI context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43837 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix null pointer dereference in resolve_prog_type() for BPF_PROG_TYPE_EXTWhen loading a EXT program without specifying `attr->attach_prog_fd`,the `prog->aux->dst_prog` will be null. At this time, callingresolve_prog_type() anywhere will result in a null pointer dereference.Example stack trace:[ 8.107863] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 8.108262] Mem abort info:[ 8.108384] ESR = 0x0000000096000004[ 8.108547] EC = 0x25: DABT (current EL), IL = 32 bits[ 8.108722] SET = 0, FnV = 0[ 8.108827] EA = 0, S1PTW = 0[ 8.108939] FSC = 0x04: level 0 translation fault[ 8.109102] Data abort info:[ 8.109203] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 8.109399] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 8.109614] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 8.109836] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101354000[ 8.110011] [0000000000000004] pgd=0000000000000000, p4d=0000000000000000[ 8.112624] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 8.112783] Modules linked in:[ 8.113120] CPU: 0 PID: 99 Comm: may_access_dire Not tainted 6.10.0-rc3-next-20240613-dirty #1[ 8.113230] Hardware name: linux,dummy-virt (DT)[ 8.113390] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 8.113429] pc : may_access_direct_pkt_data+0x24/0xa0[ 8.113746] lr : add_subprog_and_kfunc+0x634/0x8e8[ 8.113798] sp : ffff80008283b9f0[ 8.113813] x29: ffff80008283b9f0 x28: ffff800082795048 x27: 0000000000000001[ 8.113881] x26: ffff0000c0bb2600 x25: 0000000000000000 x24: 0000000000000000[ 8.113897] x23: ffff0000c1134000 x22: 000000000001864f x21: ffff0000c1138000[ 8.113912] x20: 0000000000000001 x19: ffff0000c12b8000 x18: ffffffffffffffff[ 8.113929] x17: 0000000000000000 x16: 0000000000000000 x15: 0720072007200720[ 8.113944] x14: 0720072007200720 x13: 0720072007200720 x12: 0720072007200720[ 8.113958] x11: 0720072007200720 x10: 0000000000f9fca4 x9 : ffff80008021f4e4[ 8.113991] x8 : 0101010101010101 x7 : 746f72705f6d656d x6 : 000000001e0e0f5f[ 8.114006] x5 : 000000000001864f x4 : ffff0000c12b8000 x3 : 000000000000001c[ 8.114020] x2 : 0000000000000002 x1 : 0000000000000000 x0 : 0000000000000000[ 8.114126] Call trace:[ 8.114159] may_access_direct_pkt_data+0x24/0xa0[ 8.114202] bpf_check+0x3bc/0x28c0[ 8.114214] bpf_prog_load+0x658/0xa58[ 8.114227] __sys_bpf+0xc50/0x2250[ 8.114240] __arm64_sys_bpf+0x28/0x40[ 8.114254] invoke_syscall.constprop.0+0x54/0xf0[ 8.114273] do_el0_svc+0x4c/0xd8[ 8.114289] el0_svc+0x3c/0x140[ 8.114305] el0t_64_sync_handler+0x134/0x150[ 8.114331] el0t_64_sync+0x168/0x170[ 8.114477] Code: 7100707f 54000081 f9401c00 f9403800 (b9400403)[ 8.118672] ---[ end trace 0000000000000000 ]---One way to fix it is by forcing `attach_prog_fd` non-empty whenbpf_prog_load(). But this will lead to `libbpf_probe_bpf_prog_type`API broken which use verifier log to probe prog type and will lognothing if we reject invalid EXT prog before bpf_check().Another way is by adding null check in resolve_prog_type().The issue was introduced by commit 4a9c7bbe2ed4 ("bpf: Resolve toprog->aux->dst_prog->type only for BPF_PROG_TYPE_EXT") which wantedto correct type resolution for BPF_PROG_TYPE_TRACING programs. Beforethat, the type resolution of BPF_PROG_TYPE_EXT prog actually followsthe logic below: prog->aux->dst_prog ? prog->aux->dst_prog->type : prog->type;It implies that when EXT program is not yet attached to `dst_prog`,the prog type should be EXT itself. This code worked fine in the past.So just keep using it.Fix this by returning `prog->type` for BPF_PROG_TYPE_EXT if `dst_prog`is not present in resolve_prog_type().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bna: adjust 'name' buf size of bna_tcb and bna_ccb structuresTo have enough space to write all possible sprintf() args. Currently'name' size is 16, but the first '%s' specifier may already need atleast 16 characters, since 'bnad->netdev->name' is used there.For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16And replace sprintf with snprintf.Detected using the static analysis tool - Svace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: virt_wifi: avoid reporting connection success with wrong SSIDWhen user issues a connection with a different SSID than the onevirt_wifi has advertised, the __cfg80211_connect_result() willtrigger the warning: WARN_ON(bss_not_found).The issue is because the connection code in virt_wifi does notcheck the SSID from user space (it only checks the BSSID), andvirt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESSeven if the SSID is different from the one virt_wifi has advertised.Eventually cfg80211 won't be able to find the cfg80211_bss and generatethe warning.Fixed it by checking the SSID (from user space) in the connection code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43856 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation. kokonut //net/encryption http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix array-index-out-of-bounds in diFree

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43860 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: imx_rproc: Skip over memory region when node value is NULLIn imx_rproc_addr_init() "nph = of_count_phandle_with_args()" just countsnumber of phandles. But phandles may be empty. So of_parse_phandle() inthe parsing loop (0 < a < nph) may return NULL which is later dereferenced.Adjust this issue by adding NULL-return check.Found by Linux Verification Center (linuxtesting.org) with SVACE.[Fixed title to fit within the prescribed 70-75 charcters]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a deadlock in dma buf fence pollingIntroduce a version of the fence ops that on release doesn't removethe fence from the pending list, and thus doesn't require a lock tofix poll->fence wait->fence unref deadlocks.vmwgfx overwrites the wait callback to iterate over the list of allfences and update their status, to do that it holds a lock to preventthe list modifcations from other threads. The fence destroy callbackboth deletes the fence and removes it from the list of pendingfences, for which it holds a lock.dma buf polling cb unrefs a fence after it's been signaled: so the pollcalls the wait, which signals the fences, which are being destroyed.The destruction tries to acquire the lock on the pending fences listwhich it can never get because it's held by the wait from which itwas called.Old bug, but not a lot of userspace apps were using dma-buf pollinginterfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Always drain health in shutdown callbackThere is no point in recovery during device shutdown. if healthwork started need to wait for it to avoid races and NULL pointeraccess.Hence, drain health WQ on shutdown callback.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix refcount underflowCalling nouveau_bo_ref() on a nouveau_bo without initializing it (andhence the backing ttm_bo) leads to a refcount underflow.Instead of calling nouveau_bo_ref() in the unwind path ofdrm_gem_object_init(), clean things up manually.(cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:devres: Fix memory leakage caused by driver API devm_free_percpu()It will cause memory leakage when use driver API devm_free_percpu()to free memory allocated by devm_alloc_percpu(), fixed by usingdevres_release() instead of devres_destroy() within devm_free_percpu().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup under heavy CEQE loadCEQEs are handled in interrupt handler currently. This may cause theCPU core staying in interrupt context too long and lead to soft lockupunder heavy load.Handle CEQEs in BH workqueue and set an upper limit for the number ofCEQE handled by a single call of work handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/vsock: always initialize seqpacket_allowThere are two issues around seqpacket_allow:1. seqpacket_allow is not initialized when socket is created. Thus if features are never set, it will be read uninitialized.2. if VIRTIO_VSOCK_F_SEQPACKET is set and then cleared, then seqpacket_allow will not be cleared appropriately (existing apps I know about don't usually do this but it's legal and there's no way to be sure no one relies on this).To fix: - initialize seqpacket_allow after allocation - set it unconditionally in set_features

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled incfg80211_calculate_bitrate_he(), leading to below warning:kernel: invalid HE MCS: bw:6, ru:6kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43880 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_erp: Fix object nesting warningACLs in Spectrum-2 and newer ASICs can reside in the algorithmic TCAM(A-TCAM) or in the ordinary circuit TCAM (C-TCAM). The former cancontain more ACLs (i.e., tc filters), but the number of masks in eachregion (i.e., tc chain) is limited.In order to mitigate the effects of the above limitation, the deviceallows filters to share a single mask if their masks only differ in upto 8 consecutive bits. For example, dst_ip/25 can be represented usingdst_ip/24 with a delta of 1 bit. The C-TCAM does not have a limit on thenumber of masks being used (and therefore does not support maskaggregation), but can contain a limited number of filters.The driver uses the "objagg" library to perform the mask aggregation bypassing it objects that consist of the filter's mask and whether thefilter is to be inserted into the A-TCAM or the C-TCAM since filters indifferent TCAMs cannot share a mask.The set of created objects is dependent on the insertion order of thefilters and is not necessarily optimal. Therefore, the driver willperiodically ask the library to compute a more optimal set ("hints") bylooking at all the existing objects.When the library asks the driver whether two objects can be aggregatedthe driver only compares the provided masks and ignores the A-TCAM /C-TCAM indication. This is the right thing to do since the goal is tomove as many filters as possible to the A-TCAM. The driver also forbidstwo identical masks from being aggregated since this can only happen ifone was intentionally put in the C-TCAM to avoid a conflict in theA-TCAM.The above can result in the following set of hints:H1: {mask X, A-TCAM} -> H2: {mask Y, A-TCAM} // X is Y + deltaH3: {mask Y, C-TCAM} -> H4: {mask Z, A-TCAM} // Y is Z + deltaAfter getting the hints from the library the driver will start migratingfilters from one region to another while consulting the computed hintsand instructing the device to perform a lookup in both regions duringthe transition.Assuming a filter with mask X is being migrated into the A-TCAM in thenew region, the hints lookup will return H1. Since H2 is the parent ofH1, the library will try to find the object associated with it andcreate it if necessary in which case another hints lookup (recursive)will be performed. This hints lookup for {mask Y, A-TCAM} will eitherreturn H2 or H3 since the driver passes the library an object comparisonfunction that ignores the A-TCAM / C-TCAM indication.This can eventually lead to nested objects which are not supported bythe library [1].Fix by removing the object comparison function from both the driver andthe library as the driver was the only user. That way the lookup willonly return exact matches.I do not have a reliable reproducer that can reproduce the issue in atimely manner, but before the fix the issue would reproduce in severalminutes and with the fix it does not reproduce in over an hour.Note that the current usefulness of the hints is limited because theyinclude the C-TCAM indication and represent aggregation that cannotactually happen. This will be addressed in net-next.[1]WARNING: CPU: 0 PID: 153 at lib/objagg.c:170 objagg_obj_parent_assign+0xb5/0xd0Modules linked in:CPU: 0 PID: 153 Comm: kworker/0:18 Not tainted 6.9.0-rc6-custom-g70fbc2c1c38b #42Hardware name: Mellanox Technologies Ltd. MSN3700C/VMOD0008, BIOS 5.11 10/10/2018Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:objagg_obj_parent_assign+0xb5/0xd0[...]Call Trace: __objagg_obj_get+0x2bb/0x580 objagg_obj_get+0xe/0x80 mlxsw_sp_acl_erp_mask_get+0xb5/0xf0 mlxsw_sp_acl_atcam_entry_add+0xe8/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland then enabling fullscreen playback (double click on the video)The following calltrace will be seen:[ 181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 181.843997] #PF: supervisor instruction fetch in kernel mode[ 181.844003] #PF: error_code(0x0010) - not-present page[ 181.844009] PGD 0 P4D 0[ 181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI[ 181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu[ 181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018[ 181.844044] RIP: 0010:0x0[ 181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.[ 181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246[ 181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004[ 181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400[ 181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c[ 181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8[ 181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005[ 181.844121] FS: 00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000[ 181.844128] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0[ 181.844141] Call Trace:[ 181.844146] [ 181.844153] ? show_regs+0x6d/0x80[ 181.844167] ? __die+0x24/0x80[ 181.844179] ? page_fault_oops+0x99/0x1b0[ 181.844192] ? do_user_addr_fault+0x31d/0x6b0[ 181.844204] ? exc_page_fault+0x83/0x1b0[ 181.844216] ? asm_exc_page_fault+0x27/0x30[ 181.844237] dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu][ 181.845115] amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu][ 181.845985] amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu][ 181.846848] fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu][ 181.847734] fill_dc_plane_attributes+0x162/0x350 [amdgpu][ 181.848748] dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.849791] ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu][ 181.850840] amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference for smu7optimize the code to avoid pass a null pointer (hwmgr->backend)to function smu7_update_edc_leakage_table.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: prevent potential speculation leaks in gpio_device_get_desc()Userspace may trigger a speculative read of an address outside the gpiodescriptor array.Users can do that by calling gpio_ioctl() with an offset out of range.Offset is copied from user and then used as an array index to getthe gpio descriptor without sanitization in gpio_device_get_desc().This change ensures that the offset is sanitized by usingarray_index_nospec() to mitigate any possibility of speculativeinformation leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn'tmake sure that all previous garbage has been collected when removing aport. What happens is: CPU 1 CPU 2 start gc cycle remove port acquire gc lock first wait for lock call br_multicasg_gc() directly acquire lock now but free port the port can be freed while grp timers still runningMake sure all previous gc cycles have finished by using flush_work beforefreeing the port.[1] BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699 CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861 call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792 expire_timers kernel/time/timer.c:1843 [inline] __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417 __run_timer_base kernel/time/timer.c:2428 [inline] __run_timer_base kernel/time/timer.c:2421 [inline] run_timer_base+0x111/0x190 kernel/time/timer.c:2437

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Fix null-ptr-deref in reuseport_add_sock().syzbot reported a null-ptr-deref while accessing sk2->sk_reuseport_cb inreuseport_add_sock(). [0]The repro first creates a listener with SO_REUSEPORT. Then, it createsanother listener on the same port and concurrently closes the firstlistener.The second listen() calls reuseport_add_sock() with the first listener assk2, where sk2->sk_reuseport_cb is not expected to be cleared concurrently,but the close() does clear it by reuseport_detach_sock().The problem is SCTP does not properly synchronise reuseport_alloc(),reuseport_add_sock(), and reuseport_detach_sock().The caller of reuseport_alloc() and reuseport_{add,detach}_sock() mustprovide synchronisation for sockets that are classified into the samereuseport group.Otherwise, such sockets form multiple identical reuseport groups, andall groups except one would be silently dead. 1. Two sockets call listen() concurrently 2. No socket in the same group found in sctp_ep_hashtable[] 3. Two sockets call reuseport_alloc() and form two reuseport groups 4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives incoming packetsAlso, the reported null-ptr-deref could occur.TCP/UDP guarantees that would not happen by holding the hash bucket lock.Let's apply the locking strategy to __sctp_hash_endpoint() and__sctp_unhash_endpoint().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 <42> 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f24e46039b9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42cR13:---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix null ptr deref in dtInsertEntry[syzbot reported]general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713...[Analyze]In dtInsertEntry(), when the pointer h has the same value as p, after writingname in UniStrncpy_to_le(), p->header.flag will be cleared. This will cause thepreviously true judgment "p->header.flag & BT-LEAF" to change to no after writingthe name operation, this leads to entering an incorrect branch and accessing theuninitialized object ih when judging this condition for the second time.[Fix]After got the page, check freelist first, if freelist == 0 then exit dtInsert()and return -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use helper function to calculate expect IDDelete expectation path is missing a call to the nf_expect_get_id()helper function to calculate the expectation ID, otherwise LSB of theexpectation object address is leaked to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mtrr: Check if fixed MTRRs exist before saving themMTRRs have an obsolete fixed variant for fine grained caching controlof the 640K-1MB region that uses separate MSRs. This fixed variant hasa separate capability bit in the MTRR capability MSR.So far all x86 CPUs which support MTRR have this separate bit set, so itwent unnoticed that mtrr_save_state() does not check the capability bitbefore accessing the fixed MTRR MSRs.Though on a CPU that does not support the fixed MTRR capability thisresults in a #GP. The #GP itself is harmless because the RDMSR fault ishandled gracefully, but results in a WARN_ON().Add the missing capability check to prevent this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: fix invalid FIFO access with special register setWhen enabling access to the special register set, Receiver time-out andRHR interrupts can happen. In this case, the IRQ handler will try to readfrom the FIFO thru the RHR register at address 0x00, but address 0x00 ismapped to DLL register, resulting in erroneous FIFO reading.Call graph example: sc16is7xx_startup(): entry sc16is7xx_ms_proc(): entry sc16is7xx_set_termios(): entry sc16is7xx_set_baud(): DLH/DLL = $009C --> access special register set sc16is7xx_port_irq() entry --> IIR is 0x0C sc16is7xx_handle_rx() entry sc16is7xx_fifo_read(): --> unable to access FIFO (RHR) because it is mapped to DLL (LCR=LCR_CONF_MODE_A) sc16is7xx_set_baud(): exit --> Restore access to general register setFix the problem by claiming the efr_lock mutex when accessing the Specialregister set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access. This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Prevent release of buffer in I/OWhen a task waiting for completion of a Store Data operation isinterrupted, an attempt is made to halt this operation. If this attemptfails due to a hardware or firmware problem, there is a chance that theSCLP facility might store data into buffers referenced by the originaloperation at a later time.Handle this situation by not releasing the referenced data buffers ifthe halt attempt fails. For current use cases, this might result in aleak of few pages of memory in case of a rare hardware/firmwaremalfunction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44971 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()bcm_sf2_mdio_register() calls of_phy_find_device() and thenphy_device_remove() in a loop to remove existing PHY devices.of_phy_find_device() eventually calls bus_find_device(), which callsget_device() on the returned struct device * to increment the refcount.The current implementation does not decrement the refcount, which causesmemory leak.This commit adds the missing phy_device_free() call to decrement therefcount via put_device() to balance the refcount.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj->pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last enabled at (129817): [] console_unlock+0x118/0x124hardirqs last disabled at (129818): [] el1_dbg+0x24/0x8csoftirqs last enabled at (129808): [] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix possible UAF in ip6_finish_output2()If skb_expand_head() returns NULL, skb has been freedand associated dst/idev could also have been freed.We need to hold rcu_read_lock() to make sure the dst andassociated idev are alive.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44987 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: prevent UAF in ip6_send_skb()syzbot reported an UAF in ip6_send_skb() [1]After ip6_local_out() has returned, we no longer can safelydereference rt, unless we hold rcu_read_lock().A similar issue has been fixed in commita688caa34beb ("ipv6: take rcu lock in rawv6_send_hdrinc()")Another potential issue in ip6_finish_output2() is handled in aseparate patch.[1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964 rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588 rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 sock_write_iter+0x2dd/0x400 net/socket.c:1160 do_iter_readv_writev+0x60a/0x890 vfs_writev+0x37c/0xbb0 fs/read_write.c:971 do_writev+0x1b1/0x350 fs/read_write.c:1018 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f936bf79e79Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8 Allocated by task 6530: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044 dst_alloc+0x12b/0x190 net/core/dst.c:89 ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670 make_blackhole net/xfrm/xfrm_policy.c:3120 [inline] xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313 ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257 rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 45: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kmem_cache_free+0x145/0x350 mm/slub.c:4548 dst_destroy+0x2ac/0x460 net/core/dst.c:124 rcu_do_batch kernel/rcu/tree.c:2569 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44988 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix out-of-bound accessIf an ATU violation was caused by a CPU Load operation, the SPID couldbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix xfrm real_dev null pointer dereferenceWe shouldn't set real_dev to NULL because packets can be in transit andxfrm might call xdo_dev_offload_ok() in parallel. All callbacks assumereal_dev is set. Example trace: kernel: BUG: unable to handle page fault for address: 0000000000001030 kernel: bond0: (slave eni0np1): making interface the new active one kernel: #PF: supervisor write access in kernel mode kernel: #PF: error_code(0x0002) - not-present page kernel: PGD 0 P4D 0 kernel: Oops: 0002 [#1] PREEMPT SMP kernel: CPU: 4 PID: 2237 Comm: ping Not tainted 6.7.7+ #12 kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 kernel: RIP: 0010:nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: Code: e0 0f 0b 48 83 7f 38 00 74 de 0f 0b 48 8b 47 08 48 8b 37 48 8b 78 40 e9 b2 e5 9a d7 66 90 0f 1f 44 00 00 48 8b 86 80 02 00 00 <83> 80 30 10 00 00 01 b8 01 00 00 00 c3 0f 1f 80 00 00 00 00 0f 1f kernel: bond0: (slave eni0np1): making interface the new active one kernel: RSP: 0018:ffffabde81553b98 EFLAGS: 00010246 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: kernel: RAX: 0000000000000000 RBX: ffff9eb404e74900 RCX: ffff9eb403d97c60 kernel: RDX: ffffffffc090de10 RSI: ffff9eb404e74900 RDI: ffff9eb3c5de9e00 kernel: RBP: ffff9eb3c0a42000 R08: 0000000000000010 R09: 0000000000000014 kernel: R10: 7974203030303030 R11: 3030303030303030 R12: 0000000000000000 kernel: R13: ffff9eb3c5de9e00 R14: ffffabde81553cc8 R15: ffff9eb404c53000 kernel: FS: 00007f2a77a3ad00(0000) GS:ffff9eb43bd00000(0000) knlGS:0000000000000000 kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000001030 CR3: 00000001122ab000 CR4: 0000000000350ef0 kernel: bond0: (slave eni0np1): making interface the new active one kernel: Call Trace: kernel: kernel: ? __die+0x1f/0x60 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? page_fault_oops+0x142/0x4c0 kernel: ? do_user_addr_fault+0x65/0x670 kernel: ? kvm_read_and_reset_apf_flags+0x3b/0x50 kernel: bond0: (slave eni0np1): making interface the new active one kernel: ? exc_page_fault+0x7b/0x180 kernel: ? asm_exc_page_fault+0x22/0x30 kernel: ? nsim_bpf_uninit+0x50/0x50 [netdevsim] kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ? nsim_ipsec_offload_ok+0xc/0x20 [netdevsim] kernel: bond0: (slave eni0np1): making interface the new active one kernel: bond_ipsec_offload_ok+0x7b/0x90 [bonding] kernel: xfrm_output+0x61/0x3b0 kernel: bond0: (slave eni0np1): bond_ipsec_add_sa_all: failed to add SA kernel: ip_push_pending_frames+0x56/0x80

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: fix null pointer deref in bond_ipsec_offload_okWe must check if there is an active slave before dereferencing the pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas below: pf reset start | v ......setup tc | | v v DOWN: napi_disable()napi_disable()(skip) | | | v v ...... ...... | | v |napi_enable() | v UINIT: netif_napi_del() | v ...... | v INIT: netif_napi_add() | v ...... global reset start | | v v UP: napi_enable()(skip) ...... | | v v ...... napi_disable()In reset process, the driver will DOWN the port and then UINIT, in thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can't dereference "skb" after calling vcc->push() because the skbis released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44999 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: pull network headers in gtp_dev_xmit()syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]We must make sure the IPv4 or Ipv6 header is pulled in skb->headbefore accessing fields in them.Use pskb_inet_may_pull() to fix this issue.[1]BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline] BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 ipv6_pdp_find drivers/net/gtp.c:220 [inline] gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline] gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281 __netdev_start_xmit include/linux/netdevice.h:4913 [inline] netdev_start_xmit include/linux/netdevice.h:4922 [inline] xmit_one net/core/dev.c:3580 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596 __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423 dev_queue_xmit include/linux/netdevice.h:3105 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3145 [inline] packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:3994 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815 packet_alloc_skb net/packet/af_packet.c:2994 [inline] packet_snd net/packet/af_packet.c:3088 [inline] packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:745 __sys_sendto+0x685/0x830 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212 x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Don't destroy workqueue from work item running on itTriggered by a kref decrement, destroy_workqueue() may be called fromwithin a work item for destroying its own workqueue. This illegalsituation is averted by adding a module-global workqueue for exclusiveuse of the offending work item. Other work items continue to be queuedon per-device workqueues to ensure performance.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: MT - limit max slotssyzbot is reporting too large allocation at input_mt_init_slots(), fornum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).Since nobody knows possible max slots, this patch chose 1024.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: xillybus: Check USB endpoints when probing deviceEnsure, as the driver probes the device, that all endpoints that thedriver may attempt to access exist and are of the correct type.All XillyUSB devices must have a Bulk IN and Bulk OUT endpoint ataddress 1. This is verified in xillyusb_setup_base_eps().On top of that, a XillyUSB device may have additional Bulk OUTendpoints. The information about these endpoints' addresses is deducedfrom a data structure (the IDT) that the driver fetches from the devicewhile probing it. These endpoints are checked in setup_channels().A XillyUSB device never has more than one IN endpoint, as all datatowards the host is multiplexed in this single Bulk IN endpoint. This iswhy setup_channels() only checks OUT endpoints.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45018 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: initialise extack before useFix missing initialisation of extack in flow offload.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45025 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHAREcopy_fd_bitmaps(new, old, count) is expected to copy the firstcount/BITS_PER_LONG bits from old->full_fds_bits[] and fillthe rest with zeroes. What it does is copying enough words(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.That works fine, *if* all bits past the cutoff point areclear. Otherwise we are risking garbage from the last wordwe'd copied.For most of the callers that is true - expand_fdtable() hascount equal to old->max_fds, so there's no open descriptorspast count, let alone fully occupied words in ->open_fds[],which is what bits in ->full_fds_bits[] correspond to.The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),which is the smallest multiple of BITS_PER_LONG that covers allopened descriptors below max_fds. In the common case (copying onfork()) max_fds is ~0U, so all opened descriptors will be belowit and we are fine, by the same reasons why the call in expand_fdtable()is safe.Unfortunately, there is a case where max_fds is less than thatand where we might, indeed, end up with junk in ->full_fds_bits[] -close_range(from, to, CLOSE_RANGE_UNSHARE) with * descriptor table being currently shared * 'to' being above the current capacity of descriptor table * 'from' being just under some chunk of opened descriptors.In that case we end up with observably wrong behaviour - e.g. spawna child with CLONE_FILES, get all descriptors in range 0..127 open,then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) endingup with descriptor #128, despite #64 being observably not open.The minimally invasive fix would be to deal with that in dup_fd().If this proves to add measurable overhead, we can go that way, butlet's try to fix copy_fd_bitmaps() first.* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).* make copy_fd_bitmaps() take the bitmap size in words, rather thanbits; it's 'count' argument is always a multiple of BITS_PER_LONG,so we are not losing any information, and that way we can use thesame helper for all three bitmaps - compiler will see that countis a multiple of BITS_PER_LONG for the large ones, so it'll generateplain memcpy()+memset().Reproducer added to tools/testing/selftests/core/close_range_test.c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45029 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: tegra: Do not mark ACPI devices as irq safeOn ACPI machines, the tegra i2c module encounters an issue due to amutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xferThe problem arises because during __pm_runtime_resume(), the spinlock&dev->power.lock is acquired before rpm_resume() is called. Later,rpm_resume() invokes acpi_subsys_runtime_resume(), which relies onmutexes, triggering the error.To address this issue, devices on ACPI are now marked as not IRQ-safe,considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: fix a potential NULL pointer dereferenceWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns aNULL pointer, but its callers only check for error pointers thus missthe NULL pointer case.Fix it by returning an error pointer with the error code carried fromsockfd_lookup().(I found this bug during code inspection.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46685 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereference in pcs_get_function()pinmux_generic_get_function() can return NULL and the pointer 'function'was dereferenced without checking against NULL. Add checking of pointer'function' in pcs_get_function().Found by code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb/client: avoid dereferencing rdata=NULL in smb2_new_read_req()This happens when called from SMB2_read() while using rdmaand reaching the rdma_readwrite_threshold.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: cmd-db: Map shared memory as WC, not WBLinux does not write into cmd-db region. This region of memory is writeprotected by XPU. XPU may sometime falsely detect clean cache evictionas "write" into the write protected region leading to secure interruptwhich causes an endless loop somewhere in Trust Zone.The only reason it is working right now is because Qualcomm Hypervisormaps the same region as Non-Cacheable memory in Stage 2 translationtables. The issue manifests if we want to use another hypervisor (likeXen or KVM), which does not know anything about those specific mappings.Changing the mapping of cmd-db memory from MEMREMAP_WB to MEMREMAP_WT/WCremoves dependency on correct mappings in Stage 2 tables. This patchfixes the issue by updating the mapping to MEMREMAP_WC.I tested this on SA8155P with Xen.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46695 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don't bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: * This function requires the caller to lock the inode's i_mutex before it * is executed. It also assumes that the caller will make the appropriate * permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don't do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked(). Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn't been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/aux: Fix AUX buffer serializationOle reported that event->mmap_mutex is strictly insufficient toserialize the AUX buffer, add a per RB mutex to fully serialize it.Note that in the lock order comment the perf_event::mmap_mutex orderwas already wrong, that is, it nesting under mmap_lock is not new withthis patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46714 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip wbscl_set_scaler_filter if filter is nullCallers can pass null in filter (i.e. from returned from the functionwbscl_get_filter_coeffs_16p) and a null check is added to ensure that isnot the case.This fixes 4 NULL_RETURNS issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver: iio: add missing checks on iio_info's callback accessSome callbacks from iio_info structure are accessed without any check, soif a driver doesn't implement them trying to access the correspondingsysfs entries produce a kernel oops such as:[ 2203.527791] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute[...][ 2203.783416] Call trace:[ 2203.783429] iio_read_channel_info_avail from dev_attr_show+0x18/0x48[ 2203.789807] dev_attr_show from sysfs_kf_seq_show+0x90/0x120[ 2203.794181] sysfs_kf_seq_show from seq_read_iter+0xd0/0x4e4[ 2203.798555] seq_read_iter from vfs_read+0x238/0x2a0[ 2203.802236] vfs_read from ksys_read+0xa4/0xd4[ 2203.805385] ksys_read from ret_fast_syscall+0x0/0x54[ 2203.809135] Exception stack(0xe0badfa8 to 0xe0badff0)[ 2203.812880] dfa0: 00000003 b6f10f80 00000003 b6eab000 00020000 00000000[ 2203.819746] dfc0: 00000003 b6f10f80 7ff00000 00000003 00000003 00000000 00020000 00000000[ 2203.826619] dfe0: b6e1bc88 bed80958 b6e1bc94 b6e1bcb0[ 2203.830363] Code: bad PC value[ 2203.832695] ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: SHAMPO, Fix incorrect page releaseUnder the following conditions:1) No skb created yet2) header_size == 0 (no SHAMPO header)3) header_index + 1 % MLX5E_SHAMPO_WQ_HEADER_PER_PAGE == 0 (this is the last page fragment of a SHAMPO header page)a new skb is formed with a page that is NOT a SHAMPO header page (itis a regular data page). Further down in the same function(mlx5e_handle_rx_cqe_mpwrq_shampo()), a SHAMPO header page fromheader_index is released. This is wrong and it leads to SHAMPO headerpages being released more than once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile->parent->dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and 'ent->old' is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS: 00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc <4d> 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix mc_data out-of-bounds read warningClear warning that read mc_data[i-1] may out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds read of df_v1_7_channel_numberCheck the fb_channel_number range to avoid the array out-of-boundsread error

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds write warningCheck the ring type value to fix the out-of-boundswrite warning

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix the Out-of-bounds read warningusing index i - 1U may beyond element indexfor mc_data[] when i = 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Assign linear_pitch_alignment even for VM[Description]Assign linear_pitch_alignment so we don't cause a divide by 0error in VM environments

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a "KMSAN: uninit-value in pick_link" bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage is due to the following sequence of events:1. squashfs_read_inode() is called to read the symbolic link from disk. This assigns the corrupted value 3875536935 to inode->i_size.2. Later squashfs_symlink_read_folio() is called, which assigns this corrupted value to the length variable, which being a signed int, overflows producing a negative number.3. The following loop that fills in the page contents checks that the copied bytes is less than length, which being negative means the loop is skipped, producing an uninitialised page.This patch adds a sanity check which checks that the symboliclink size is not larger than expected.--V2: fix spelling mistake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem which will try to free a lot of memory for a bogus request.Fix it by limiting allowed number of slots to 100. This can easilybe extended if we see devices that can track more than 100 contacts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46751 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,aborting the transaction and logging an error message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46752 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: replace BUG_ON() with error handling at update_ref_for_cow()Instead of a BUG_ON() just return an error, log an error message andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn't have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref(). This isincorrect, we have proper error handling here, return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46755 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack. Fixthis by returning only used priv pointers which have priv->bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={ ssid="somessid" mode=2 frequency=2412 key_mgmt=WPA-PSK WPA-PSK-SHA256 proto=RSN group=CCMP pairwise=CCMP psk="12345678"}When waiting for the AP to be established, interrupting wpa_supplicantwith and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| Mem abort info:| ESR = 0x0000000096000004| EC = 0x25: DABT (current EL), IL = 32 bits| SET = 0, FnV = 0| EA = 0, S1PTW = 0| FSC = 0x04: level 0 translation fault| Data abort info:| ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000| CM = 0, WnR = 0, TnD = 0, TagAccess = 0| GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:| mwifiex_get_cfp+0xd8/0x15c [mwifiex]| mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]| mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]| mwifiex_process_sta_event+0x298/0xf0c [mwifiex]| mwifiex_process_event+0x110/0x238 [mwifiex]| mwifiex_main_process+0x428/0xa44 [mwifiex]| mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]| process_sdio_pending_irqs+0x64/0x1b8| sdio_irq_work+0x4c/0x7c| process_one_work+0x148/0x2a0| worker_thread+0x2fc/0x40c| kthread+0x110/0x114| ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fou: Fix null-ptr-deref in GRO.We observed a null-ptr-deref in fou_gro_receive() while shutting downa host. [0]The NULL pointer is sk->sk_user_data, and the offset 8 is of protocolin struct fou.When fou_release() is called due to netns dismantle or explicit tunnelteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.Then, the tunnel socket is destroyed after a single RCU grace period.So, in-flight udp4_gro_receive() could find the socket and execute theFOU GRO handler, where sk->sk_user_data could be NULL.Let's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULLchecks in FOU GRO handlers.[0]:BUG: kernel NULL pointer dereference, address: 0000000000000008 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0SMP PTICPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1Hardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017RIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]Code: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42RSP: 0018:ffffa330c0003d08 EFLAGS: 00010297RAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010RDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08RBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002R10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400R13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0FS: 0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? no_context (arch/x86/mm/fault.c:752) ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483) ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571) ? fou_gro_receive (net/ipv4/fou.c:233) [fou] udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559) udp4_gro_receive (net/ipv4/udp_offload.c:604) inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7)) dev_gro_receive (net/core/dev.c:6035 (discriminator 4)) napi_gro_receive (net/core/dev.c:6170) ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena] ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena] napi_poll (net/core/dev.c:6847) net_rx_action (net/core/dev.c:6917) __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299) asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809) do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77) irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435) common_interrupt (arch/x86/kernel/irq.c:239) asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)RIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)Code: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00RSP: 0018:ffffffffb5603e58 EFLAGS: 00000246RAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900RDX: ffff93daee800000 RSI: ffff93d---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: protect XDP configuration with a mutexThe main threat to data consistency in ice_xdp() is a possible asynchronousPF reset. It can be triggered by a user or by TX timeout handler.XDP setup and PF reset code access the same resources in the followingsections:* ice_vsi_close() in ice_prepare_for_reset() - already rtnl-locked* ice_vsi_rebuild() for the PF VSI - not protected* ice_vsi_open() - already rtnl-lockedWith an unfortunate timing, such accesses can result in a crash such as theone below:[ +1.999878] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 14[ +2.002992] ice 0000:b1:00.0: Registered XDP mem model MEM_TYPE_XSK_BUFF_POOL on Rx ring 18[Mar15 18:17] ice 0000:b1:00.0 ens801f0np0: NETDEV WATCHDOG: CPU: 38: transmit queue 14 timed out 80692736 ms[ +0.000093] ice 0000:b1:00.0 ens801f0np0: tx_timeout: VSI_num: 6, Q 14, NTC: 0x0, HW_HEAD: 0x0, NTU: 0x0, INT: 0x4000001[ +0.000012] ice 0000:b1:00.0 ens801f0np0: tx_timeout recovery level 1, txqueue 14[ +0.394718] ice 0000:b1:00.0: PTP reset successful[ +0.006184] BUG: kernel NULL pointer dereference, address: 0000000000000098[ +0.000045] #PF: supervisor read access in kernel mode[ +0.000023] #PF: error_code(0x0000) - not-present page[ +0.000023] PGD 0 P4D 0[ +0.000018] Oops: 0000 [#1] PREEMPT SMP NOPTI[ +0.000023] CPU: 38 PID: 7540 Comm: kworker/38:1 Not tainted 6.8.0-rc7 #1[ +0.000031] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021[ +0.000036] Workqueue: ice ice_service_task [ice][ +0.000183] RIP: 0010:ice_clean_tx_ring+0xa/0xd0 [ice][...][ +0.000013] Call Trace:[ +0.000016] [ +0.000014] ? __die+0x1f/0x70[ +0.000029] ? page_fault_oops+0x171/0x4f0[ +0.000029] ? schedule+0x3b/0xd0[ +0.000027] ? exc_page_fault+0x7b/0x180[ +0.000022] ? asm_exc_page_fault+0x22/0x30[ +0.000031] ? ice_clean_tx_ring+0xa/0xd0 [ice][ +0.000194] ice_free_tx_ring+0xe/0x60 [ice][ +0.000186] ice_destroy_xdp_rings+0x157/0x310 [ice][ +0.000151] ice_vsi_decfg+0x53/0xe0 [ice][ +0.000180] ice_vsi_rebuild+0x239/0x540 [ice][ +0.000186] ice_vsi_rebuild_by_type+0x76/0x180 [ice][ +0.000145] ice_rebuild+0x18c/0x840 [ice][ +0.000145] ? delay_tsc+0x4a/0xc0[ +0.000022] ? delay_tsc+0x92/0xc0[ +0.000020] ice_do_reset+0x140/0x180 [ice][ +0.000886] ice_service_task+0x404/0x1030 [ice][ +0.000824] process_one_work+0x171/0x340[ +0.000685] worker_thread+0x277/0x3a0[ +0.000675] ? preempt_count_add+0x6a/0xa0[ +0.000677] ? _raw_spin_lock_irqsave+0x23/0x50[ +0.000679] ? __pfx_worker_thread+0x10/0x10[ +0.000653] kthread+0xf0/0x120[ +0.000635] ? __pfx_kthread+0x10/0x10[ +0.000616] ret_from_fork+0x2d/0x50[ +0.000612] ? __pfx_kthread+0x10/0x10[ +0.000604] ret_from_fork_asm+0x1b/0x30[ +0.000604] The previous way of handling this through returning -EBUSY is not viable,particularly when destroying AF_XDP socket, because the kernel proceedswith removal anyway.There is plenty of code between those calls and there is no need to createa large critical section that covers all of them, same as there is no needto protect ice_vsi_rebuild() with rtnl_lock().Add xdp_state_lock mutex to protect ice_vsi_rebuild() and ice_xdp().Leaving unprotected sections in between would result in two states thathave to be considered:1. when the VSI is closed, but not yet rebuild2. when VSI is already rebuild, but not yet openThe latter case is actually already handled through !netif_running() case,we just need to adjust flag checking a little. The former one is not astrivial, because between ice_vsi_close() and ice_vsi_rebuild(), a lot ofhardware interaction happens, this can make adding/deleting rings exitwith an error. Luckily, VSI rebuild is pending and can apply newconfiguration for us in a managed fashion.Therefore, add an additional VSI state flag ICE_VSI_REBUILD_PENDING toindicate that ice_x---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset: # echo 1 > /sys/class/net//device/resetwhen reset is in progress try to get coalesce settings using ethtool: # ethtool -c BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS: 00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message: netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)->bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)->bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)->bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let's clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry 'can-bcm/2456' already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 <0f> 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS: 00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 remove_proc_entry: removing non-empty directory 'net/can-bcm', leaking at least '2456'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: protect references to superblock parameters exposed in sysfsThe superblock buffers of nilfs2 can not only be overwritten at runtimefor modifications/repairs, but they are also regularly swapped, replacedduring resizing, and even abandoned when degrading to one side due tobacking device issues. So, accessing them requires mutual exclusion usingthe reader/writer semaphore "nilfs->ns_sem".Some sysfs attribute show methods read this superblock buffer without thenecessary mutual exclusion, which can cause problems with pointerdereferencing and memory access, so fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix missing cleanup on rollforward recovery errorIn an error injection test of a routine for mount-time recovery, KASANfound a use-after-free bug.It turned out that if data recovery was performed using partial logscreated by dsync writes, but an error occurred before starting the logwriter to create a recovered checkpoint, the inodes whose data had beenrecovered were left in the ns_dirty_files list of the nilfs object andwere not freed.Fix this issue by cleaning up inodes that have read the recovery data ifthe recovery routine fails midway before the log writer starts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ila: call nf_unregister_net_hooks() soonersyzbot found an use-after-free Read in ila_nf_input [1]Issue here is that ila_xlat_exit_net() frees the rhashtable,then call nf_unregister_net_hooks().It should be done in the reverse way, with a synchronize_rcu().This is a good match for a pre_exit() method.[1] BUG: KASAN: use-after-free in rht_key_hashfn include/linux/rhashtable.h:159 [inline] BUG: KASAN: use-after-free in __rhashtable_lookup include/linux/rhashtable.h:604 [inline] BUG: KASAN: use-after-free in rhashtable_lookup include/linux/rhashtable.h:646 [inline] BUG: KASAN: use-after-free in rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672Read of size 4 at addr ffff888064620008 by task ksoftirqd/0/16CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.11.0-rc4-syzkaller-00238-g2ad6d23f465a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 rht_key_hashfn include/linux/rhashtable.h:159 [inline] __rhashtable_lookup include/linux/rhashtable.h:604 [inline] rhashtable_lookup include/linux/rhashtable.h:646 [inline] rhashtable_lookup_fast+0x77a/0x9b0 include/linux/rhashtable.h:672 ila_lookup_wildcards net/ipv6/ila/ila_xlat.c:132 [inline] ila_xlat_addr net/ipv6/ila/ila_xlat.c:652 [inline] ila_nf_input+0x1fe/0x3c0 net/ipv6/ila/ila_xlat.c:190 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK+0x29e/0x450 include/linux/netfilter.h:312 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1ea/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6108 __napi_poll+0xcb/0x490 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6963 handle_softirqs+0x2c4/0x970 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:928 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x64620flags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)page_type: 0xbfffffff(buddy)raw: 00fff00000000000 ffffea0000959608 ffffea00019d9408 0000000000000000raw: 0000000000000000 0000000000000003 00000000bfffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 3, migratetype Unmovable, gfp_mask 0x52dc0(GFP_KERNEL|__GFP_NOWARN|__GFP_NORETRY|__GFP_COMP|__GFP_ZERO), pid 5242, tgid 5242 (syz-executor), ts 73611328570, free_ts 618981657187 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1493 prep_new_page mm/page_alloc.c:1501 [inline] get_page_from_freelist+0x2e4c/0x2f10 mm/page_alloc.c:3439 __alloc_pages_noprof+0x256/0x6c0 mm/page_alloc.c:4695 __alloc_pages_node_noprof include/linux/gfp.h:269 [inline] alloc_pages_node_noprof include/linux/gfp.h:296 [inline] ___kmalloc_large_node+0x8b/0x1d0 mm/slub.c:4103 __kmalloc_large_node_noprof+0x1a/0x80 mm/slub.c:4130 __do_kmalloc_node mm/slub.c:4146 [inline] __kmalloc_node_noprof+0x2d2/0x440 mm/slub.c:4164 __kvmalloc_node_noprof+0x72/0x190 mm/util.c:650 bucket_table_alloc lib/rhashtable.c:186 [inline] rhashtable_init_noprof+0x534/0xa60 lib/rhashtable.c:1071 ila_xlat_init_net+0xa0/0x110 net/ipv6/ila/ila_xlat.c:613 ops_ini---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: fix return value of tcp_bpf_sendmsg()When we cork messages in psock->cork, the last message triggers theflushing will result in sending a sk_msg larger than the currentmessage size. In this case, in tcp_bpf_send_verdict(), 'copied' becomesnegative at least in the following case:468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta); // <==== HERE473 return -EACCES;Therefore, it could lead to the following BUG with a proper value of'copied' (thanks to syzbot). We should not use negative 'copied' as areturn value here. ------------[ cut here ]------------ kernel BUG at net/socket.c:733! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 0 UID: 0 PID: 3265 Comm: syz-executor510 Not tainted 6.11.0-rc3-syzkaller-00060-gd07b43284ab3 #0 Hardware name: linux,dummy-virt (DT) pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : sock_sendmsg_nosec net/socket.c:733 [inline] pc : sock_sendmsg_nosec net/socket.c:728 [inline] pc : __sock_sendmsg+0x5c/0x60 net/socket.c:745 lr : sock_sendmsg_nosec net/socket.c:730 [inline] lr : __sock_sendmsg+0x54/0x60 net/socket.c:745 sp : ffff800088ea3b30 x29: ffff800088ea3b30 x28: fbf00000062bc900 x27: 0000000000000000 x26: ffff800088ea3bc0 x25: ffff800088ea3bc0 x24: 0000000000000000 x23: f9f00000048dc000 x22: 0000000000000000 x21: ffff800088ea3d90 x20: f9f00000048dc000 x19: ffff800088ea3d90 x18: 0000000000000001 x17: 0000000000000000 x16: 0000000000000000 x15: 000000002002ffaf x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff8000815849c0 x9 : ffff8000815b49c0 x8 : 0000000000000000 x7 : 000000000000003f x6 : 0000000000000000 x5 : 00000000000007e0 x4 : fff07ffffd239000 x3 : fbf00000062bc900 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 00000000fffffdef Call trace: sock_sendmsg_nosec net/socket.c:733 [inline] __sock_sendmsg+0x5c/0x60 net/socket.c:745 ____sys_sendmsg+0x274/0x2ac net/socket.c:2597 ___sys_sendmsg+0xac/0x100 net/socket.c:2651 __sys_sendmsg+0x84/0xe0 net/socket.c:2680 __do_sys_sendmsg net/socket.c:2689 [inline] __se_sys_sendmsg net/socket.c:2687 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2687 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x48/0x110 arch/arm64/kernel/syscall.c:49 el0_svc_common.constprop.0+0x40/0xe0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x1c/0x28 arch/arm64/kernel/syscall.c:151 el0_svc+0x34/0xec arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x100/0x12c arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:598 Code: f9404463 d63f0060 3108441f 54fffe81 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series "userfaultfd: fix races around pmd_trans_huge() check", v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways depending on kernel version:1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit the right two race windows) - I've tested this in a kernel build with some extra mdelay() calls. See the commit message for a description of the race scenario. On older kernels (before 6.5), I think the same bug can even theoretically lead to accessing transhuge page contents as a page table if you hit the right 5 narrow race windows (I haven't tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for detecting PMDs that don't point to page tables. On older kernels (before 6.5), you'd just have to win a single fairly wide race to hit this. I've tested this on 6.1 stable by racing migration (with a mdelay() patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86 VM, that causes a kernel oops in ptlock_ptr().3. On newer kernels (>=6.5), for shmem mappings, khugepaged is allowed to yank page tables out from under us (though I haven't tested that), so I think the BUG_ON() checks in mfill_atomic() are just wrong.I decided to write two separate fixes for these (one fix for bugs 1+2, onefix for bug 3), so that the first fix can be backported to kernelsaffected by bugs 1+2.This patch (of 2):This fixes two issues.I discovered that the following race can occur: mfill_atomic other thread ============ ============ pmdp_get_lockless() [reads none pmd] __pte_alloc [no-op] BUG_ON(pmd_none(*dst_pmd))I have experimentally verified this in a kernel with extra mdelay() calls;the BUG_ON(pmd_none(*dst_pmd)) triggers.On kernels newer than commit 0d940a9b270b ("mm/pgtable: allowpte_offset_map[_lock]() to fail"), this can't lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(<=6.4), I think we could probably theoretically race past the twoBUG_ON() checks and end up treating a hugepage as a page table.The second issue is that, as Qi Zheng pointed out, there are other typesof huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs(in particular, migration PMDs).On <=6.4, this is worse than the first issue: If mfill_atomic() runs on aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no "struct page" for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding "struct page" thanks to the PTE inversion mitigation, amd64looks different).If that didn't crash, the kernel would next try to write a PTE into whatit wrongly thinks is a page table.As part of fixing these issues, get rid of the check for pmd_trans_huge()before __pte_alloc() - that's redundant, we're going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_openThe mcp251x_hw_wake() function is called with the mpc_lock mutex held anddisables the interrupt handler so that no interrupts can be processed whilewaking the device. If an interrupt has already occurred then waiting forthe interrupt handler to complete will deadlock because it will be tryingto acquire the same mutex.CPU0 CPU1---- ----mcp251x_open() mutex_lock(&priv->mcp_lock) request_threaded_irq() mcp251x_can_ist() mutex_lock(&priv->mcp_lock) mcp251x_hw_wake() disable_irq() <-- deadlockUse disable_irq_nosync() instead because the interrupt handler doeseverything while holding the mutex so it doesn't matter if it's stillrunning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46798 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: dapm: Fix UAF for snd_soc_pcm_runtime objectWhen using kernel with the following extra config, - CONFIG_KASAN=y - CONFIG_KASAN_GENERIC=y - CONFIG_KASAN_INLINE=y - CONFIG_KASAN_VMALLOC=y - CONFIG_FRAME_WARN=4096kernel detects that snd_pcm_suspend_all() access a freed'snd_soc_pcm_runtime' object when the system is suspended, whichleads to a use-after-free bug:[ 52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270[ 52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330[ 52.047785] Call trace:[ 52.047787] dump_backtrace+0x0/0x3c0[ 52.047794] show_stack+0x34/0x50[ 52.047797] dump_stack_lvl+0x68/0x8c[ 52.047802] print_address_description.constprop.0+0x74/0x2c0[ 52.047809] kasan_report+0x210/0x230[ 52.047815] __asan_report_load1_noabort+0x3c/0x50[ 52.047820] snd_pcm_suspend_all+0x1a8/0x270[ 52.047824] snd_soc_suspend+0x19c/0x4e0The snd_pcm_sync_stop() has a NULL check on 'substream->runtime' beforemaking any access. So we need to always set 'substream->runtime' to NULLeverytime we kfree() it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: added NULL check at start of dc_validate_stream[Why]prevent invalid memory access[How]check if dc and stream are NULL

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check BIOS images before it is usedBIOS images may fail to load and null checks are added before they areused.This fixes 6 NULL_RETURNS issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46811 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index may exceed array range within fpu_update_bw_bounding_box[Why]Coverity reports OVERRUN warning. soc.num_states couldbe 40. But array range of bw_params->clk_table.entries is 8.[How]Assert if soc.num_states greater than 8.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: acpi: Harden get_cpu_for_acpi_id() against missing CPU entryIn a review discussion of the changes to support vCPU hotplug wherea check was added on the GICC being enabled if was online, it wasnoted that there is need to map back to the cpu and use that to indexinto a cpumask. As such, a valid ID is needed.If an MPIDR check fails in acpi_map_gic_cpu_interface() it is possiblefor the entry in cpu_madt_gicc[cpu] == NULL. This function wouldthen cause a NULL pointer dereference. Whilst a path to triggerthis has not been established, harden this caller against thepossibility.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46826 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ELF: fix kernel.randomize_va_space double readELF loader uses "randomize_va_space" twice. It is sysctl and can changeat any moment, so 2 loads could see 2 different values in theory withunpredictable consequences.Issue exactly one load for consistent value across one exec.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: sch_cake: fix bulk flow accounting logic for host fairnessIn sch_cake, we keep track of the count of active bulk flows per host,when running in dst/src host fairness mode, which is used as theround-robin weight when iterating through flows. The count of activebulk flows is updated whenever a flow changes state.This has a peculiar interaction with the hash collision handling: when ahash collision occurs (after the set-associative hashing), the state ofthe hash bucket is simply updated to match the new packet that collided,and if host fairness is enabled, that also means assigning new per-hoststate to the flow. For this reason, the bulk flow counters of thehost(s) assigned to the flow are decremented, before new state isassigned (and the counters, which may not belong to the same hostanymore, are incremented again).Back when this code was introduced, the host fairness mode was alwaysenabled, so the decrement was unconditional. When the configurationflags were introduced the *increment* was made conditional, butthe *decrement* was not. Which of course can lead to a spuriousdecrement (and associated wrap-around to U16_MAX).AFAICT, when host fairness is disabled, the decrement and wrap-aroundhappens as soon as a hash collision occurs (which is not that common initself, due to the set-associative hashing). However, in most cases thisis harmless, as the value is only used when host fairness mode isenabled. So in order to trigger an array overflow, sch_cake has to firstbe configured with host fairness disabled, and while running in thismode, a hash collision has to occur to cause the overflow. Then, theqdisc has to be reconfigured to enable host fairness, which leads to thearray out-of-bounds because the wrapped-around value is retained andused as an array index. It seems that syzbot managed to trigger this,which is quite impressive in its own right.This patch fixes the issue by introducing the same conditional check ondecrement as is used on increment.The original bug predates the upstreaming of cake, but the commit listedin the Fixes tag touched that code, meaning that this patch won't applybefore that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren'tholding a lock on the extent leaf and thus could get a transientincorrect answer. In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption. Change that to return-EUCLEAN. In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling. Also adjust the error message so we canactually do something with the information.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn't fatal, return the error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Handle mailbox timeouts in lpfc_get_sfp_infoThe MBX_TIMEOUT return code is not handled in lpfc_get_sfp_info and theroutine unconditionally frees submitted mailbox commands regardless ofreturn status. The issue is that for MBX_TIMEOUT cases, when firmwarereturns SFP information at a later time, that same mailbox memory regionreferences previously freed memory in its cmpl routine.Fix by adding checks for the MBX_TIMEOUT return code. During mailboxresource cleanup, check the mbox flag to make sure that the wait did nottimeout. If the MBOX_WAKE flag is not set, then do not free the resourcesbecause it will be freed when firmware completes the mailbox at a latertime in its cmpl routine.Also, increase the timeout from 30 to 60 seconds to accommodate bootscripts requiring longer timeouts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck! WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174 intel_pmu_handle_irq+0x285/0x370 Call Trace: ? __warn+0xa4/0x220 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? __report_bug+0x123/0x130 ? intel_pmu_handle_irq+0x285/0x370 ? report_bug+0x3e/0xa0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? irq_work_claim+0x1e/0x40 ? intel_pmu_handle_irq+0x285/0x370 perf_event_nmi_handler+0x3d/0x60 nmi_handle+0x104/0x330Thanks to Thomas Gleixner's analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message'interrupt took too long' can be observed on any counter which was armedwith a period < 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: heaps: Fix off-by-one in CMA heap fault handlerUntil VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps:Don't track CMA dma-buf pages under RssFile") it was possible to obtaina mapping larger than the buffer size via mremap and bypass the overflowcheck in dma_buf_mmap_internal. When using such a mapping to attempt tofault past the end of the buffer, the CMA heap fault handler also checksthe fault offset against the buffer size, but gets the boundary wrong by1. Fix the boundary check so that we don't read off the end of the pagesarray and insert an arbitrary page in the mapping.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: nxp-fspi: fix the KASAN report out-of-bounds bugChange the memcpy length to fix the out-of-bounds issue when writing thedata that is not 4 byte aligned to TX FIFO.To reproduce the issue, write 3 bytes data to NOR chip.dd if=3b of=/dev/mtd0[ 36.926103] ==================================================================[ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838[ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455[ 36.946721][ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070[ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT)[ 36.961260] Call trace:[ 36.963723] dump_backtrace+0x90/0xe8[ 36.967414] show_stack+0x18/0x24[ 36.970749] dump_stack_lvl+0x78/0x90[ 36.974451] print_report+0x114/0x5cc[ 36.978151] kasan_report+0xa4/0xf0[ 36.981670] __asan_report_load_n_noabort+0x1c/0x28[ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838[ 36.990800] spi_mem_exec_op+0x8ec/0xd30[ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0[ 36.999323] spi_mem_dirmap_write+0x238/0x32c[ 37.003710] spi_nor_write_data+0x220/0x374[ 37.007932] spi_nor_write+0x110/0x2e8[ 37.011711] mtd_write_oob_std+0x154/0x1f0[ 37.015838] mtd_write_oob+0x104/0x1d0[ 37.019617] mtd_write+0xb8/0x12c[ 37.022953] mtdchar_write+0x224/0x47c[ 37.026732] vfs_write+0x1e4/0x8c8[ 37.030163] ksys_write+0xec/0x1d0[ 37.033586] __arm64_sys_write+0x6c/0x9c[ 37.037539] invoke_syscall+0x6c/0x258[ 37.041327] el0_svc_common.constprop.0+0x160/0x22c[ 37.046244] do_el0_svc+0x44/0x5c[ 37.049589] el0_svc+0x38/0x78[ 37.052681] el0t_64_sync_handler+0x13c/0x158[ 37.057077] el0t_64_sync+0x190/0x194[ 37.060775][ 37.062274] Allocated by task 455:[ 37.065701] kasan_save_stack+0x2c/0x54[ 37.069570] kasan_save_track+0x20/0x3c[ 37.073438] kasan_save_alloc_info+0x40/0x54[ 37.077736] __kasan_kmalloc+0xa0/0xb8[ 37.081515] __kmalloc_noprof+0x158/0x2f8[ 37.085563] mtd_kmalloc_up_to+0x120/0x154[ 37.089690] mtdchar_write+0x130/0x47c[ 37.093469] vfs_write+0x1e4/0x8c8[ 37.096901] ksys_write+0xec/0x1d0[ 37.100332] __arm64_sys_write+0x6c/0x9c[ 37.104287] invoke_syscall+0x6c/0x258[ 37.108064] el0_svc_common.constprop.0+0x160/0x22c[ 37.112972] do_el0_svc+0x44/0x5c[ 37.116319] el0_svc+0x38/0x78[ 37.119401] el0t_64_sync_handler+0x13c/0x158[ 37.123788] el0t_64_sync+0x190/0x194[ 37.127474][ 37.128977] The buggy address belongs to the object at ffff00081037c2a0[ 37.128977] which belongs to the cache kmalloc-8 of size 8[ 37.141177] The buggy address is located 0 bytes inside of[ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3)[ 37.153465][ 37.154971] The buggy address belongs to the physical page:[ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c[ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff)[ 37.175149] page_type: 0xfdffffff(slab)[ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000[ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000[ 37.194553] page dumped because: kasan: bad access detected[ 37.200144][ 37.201647] Memory state around the buggy address:[ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc[ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc[ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc[ 37.228186] ^[ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc[ 37.246962] ==============================================================---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46855 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_socket: fix sk refcount leaksWe must put 'sk' reference before returning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix bridge mode operations when there are no VFsCurrently, trying to set the bridge mode attribute when numvfs=0 leads to acrash:bridge link set dev eth2 hwmode vepa[ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030[...][ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core][...][ 168.976037] Call Trace:[ 168.976188] [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core][ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core][ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0[ 168.979714] rtnetlink_rcv_msg+0x159/0x400[ 168.980451] netlink_rcv_skb+0x54/0x100[ 168.980675] netlink_unicast+0x241/0x360[ 168.980918] netlink_sendmsg+0x1f6/0x430[ 168.981162] ____sys_sendmsg+0x3bb/0x3f0[ 168.982155] ___sys_sendmsg+0x88/0xd0[ 168.985036] __sys_sendmsg+0x59/0xa0[ 168.985477] do_syscall_64+0x79/0x150[ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 168.987773] RIP: 0033:0x7f8f7950f917(esw->fdb_table.legacy.vepa_fdb is null)The bridge mode is only relevant when there are multiple functions perport. Therefore, prevent setting and getting this setting when there are noVFs.Note that after this change, there are no settings to change on the PFinterface using `bridge link` when there are no VFs, so the interface nolonger appears in the `bridge link` output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition: CPU1 CPU2 ==== ==== net_rx_action napi_poll netlink_sendmsg __napi_poll netlink_unicast process_backlog netlink_unicast_kernel __netif_receive_skb genl_rcv __netif_receive_skb_one_core netlink_rcv_skb NF_HOOK genl_rcv_msg ip_local_deliver_finish genl_family_rcv_msg ip_protocol_deliver_rcu genl_family_rcv_msg_doit tcp_v4_rcv mptcp_pm_nl_flush_addrs_doit tcp_v4_do_rcv mptcp_nl_remove_addrs_list tcp_rcv_established mptcp_pm_remove_addrs_and_subflows tcp_data_queue remove_anno_list_by_saddr mptcp_incoming_options mptcp_pm_del_add_timer mptcp_pm_del_add_timer kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by "pm.lock", the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of "entry->add_timer".Move list_del(&entry->list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar "entry->x" uaf.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: panasonic-laptop: Fix SINF array out of bounds accessesThe panasonic laptop code in various places uses the SINF array with indexvalues of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF arrayis big enough.Not all panasonic laptops have this many SINF array entries, for examplethe Toughbook CF-18 model only has 10 SINF array entries. So it onlysupports the AC+DC brightness entries and mute.Check that the SINF array has a minimum size which covers all AC+DCbrightness entries and refuse to load if the SINF array is smaller.For higher SINF indexes hide the sysfs attributes when the SINF arraydoes not contain an entry for that attribute, avoiding show()/store()accessing the array out of bounds and add bounds checking to the probe()and resume() code accessing these.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Set phy->enable_completion only when we wait for itpm8001_phy_control() populates the enable_completion pointer with a stackaddress, sends a PHY_LINK_RESET / PHY_HARD_RESET, waits 300 ms, andreturns. The problem arises when a phy control response comes late. After300 ms the pm8001_phy_control() function returns and the passedenable_completion stack address is no longer valid. Late phy controlresponse invokes complete() on a dangling enable_completion pointer whichleads to a kernel crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_xattr_find_entry()Add a paranoia check to make sure it doesn't stray beyond valid memoryregion containing ocfs2 xattr entries when scanning for a match. It willprevent out-of-bound access in case of crafted images.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:icmp: change the order of rate limitsICMP messages are ratelimited :After the blamed commits, the two rate limiters are applied in this order:1) host wide ratelimit (icmp_global_allow())2) Per destination ratelimit (inetpeer based)In order to avoid side-channels attacks, we need to applythe per destination check first.This patch makes the following change :1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3)2) The per destination limit is checked/updated. This might add a new node in inetpeer tree.3) icmp_global_consume() consumes tokens if prior operations succeeded.This means that host wide ratelimit is still effectivein keeping inetpeer tree small even under DDOS.As a bonus, I removed icmp_global.lock as the fast pathcan use a lock-free operation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47692 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: return -EINVAL when namelen is 0When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it mayresult in namelen being 0, which will cause memdup_user() to returnZERO_SIZE_PTR.When we access the name.data that has been assigned the value ofZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference istriggered.[ T1205] ==================================================================[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205[ T1205][ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014[ T1205] Call Trace:[ T1205] dump_stack+0x9a/0xd0[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] __kasan_report.cold+0x34/0x84[ T1205] ? nfs4_client_to_reclaim+0xe9/0x260[ T1205] kasan_report+0x3a/0x50[ T1205] nfs4_client_to_reclaim+0xe9/0x260[ T1205] ? nfsd4_release_lockowner+0x410/0x410[ T1205] cld_pipe_downcall+0x5ca/0x760[ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0[ T1205] ? down_write_killable_nested+0x170/0x170[ T1205] ? avc_policy_seqno+0x28/0x40[ T1205] ? selinux_file_permission+0x1b4/0x1e0[ T1205] rpc_pipe_write+0x84/0xb0[ T1205] vfs_write+0x143/0x520[ T1205] ksys_write+0xc9/0x170[ T1205] ? __ia32_sys_read+0x50/0x50[ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110[ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110[ T1205] do_syscall_64+0x33/0x40[ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1[ T1205] RIP: 0033:0x7fdbdb761bc7[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000[ T1205] ==================================================================Fix it by checking namelen.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix potential invalid pointer dereference in blk_add_partitionThe blk_add_partition() function initially used a single if-condition(IS_ERR(part)) to check for errors when adding a partition. This wasmodified to handle the specific case of -ENXIO separately, allowing thefunction to proceed without logging the error in this case. However,this change unintentionally left a path where md_autodetect_dev()could be called without confirming that part is a valid pointer.This commit separates the error handling logic by splitting theinitial if-condition, improving code readability and handling specificerror scenarios explicitly. The function now distinguishes the generalerror case from -ENXIO without altering the existing behavior ofmd_autodetect_dev() calls.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()Blamed commit accidentally removed a check for rt->rt6i_idev being NULL,as spotted by syzbot:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8cR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f1acc77def9Code: Unable to access opcode bytes at 0x7f1acc77decf.RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in:---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06RSP: 0018:ffffc900047374e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0R---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()Since '__dev_queue_xmit()' should be called with interrupts enabled,the following backtrace:ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags)issues the warning (as reported by syzbot reproducer):WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120Fix this by implementing a two-phase skb reclamation in'ieee80211_do_stop()', where actual work is performedoutside of a section with interrupts disabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/qm - inject error before stopping queueThe master ooo cannot be completely closed when theaccelerator core reports memory error. Therefore, the driverneeds to inject the qm error to close the master ooo. Currently,the qm error is injected after stopping queue, memory may bereleased immediately after stopping queue, causing the device toaccess the released memory. Therefore, error is injected to close masterooo before stopping queue to ensure that the device does not accessthe released memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabledFix missuse of spin_lock_irq()/spin_unlock_irq() whenspin_lock_irqsave()/spin_lock_irqrestore() was hold.This was discovered through the lock debugging, and the correspondinglog is as follows:raw_local_irq_restore() called with IRQs enabledWARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40...Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: handle overlapped pclusters out of crafted images properlysyzbot reported a task hang issue due to a deadlock case where it iswaiting for the folio lock of a cached folio that will be used forcache I/Os.After looking into the crafted fuzzed image, I found it's formed withseveral overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384...Here, extent 0/1 are physically overlapped although it's entirely_impossible_ for normal filesystem images generated by mkfs.First, managed folios containing compressed data will be marked asup-to-date and then unlocked immediately (unlike in-place folios) whencompressed I/Os are complete. If physical blocks are not submitted inthe incremental order, there should be separate BIOs to avoid dependencyissues. However, the current code mis-arranges z_erofs_fill_bio_vec()and BIO submission which causes unexpected BIO waits.Second, managed folios will be connected to their own pclusters forefficient inter-queries. However, this is somewhat hard to implementeasily if overlapped big pclusters exist. Again, these only appear infuzzed images so let's simply fall back to temporary short-lived pagesfor correctness.Additionally, it justifies that referenced managed folios cannot betruncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidyup `struct z_erofs_bvec`") for simplicity although it shouldn't be anydifference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47738 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don't use rate mask for offchannel TX eitherLike the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask forscanning"), ignore incorrect settings to avoid no supported rate warningreported by syzbot.The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211:fix default HE tx bitrate mask in 2G band"), which however correctsbitmask of HE MCS and recognizes correctly settings of empty legacy rateplus HE MCS rate instead of returning -EINVAL.As suggestions [1], follow the change of SCAN TX to consider this case ofoffchannel TX as well.[1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: use integer wrap around to prevent deadlock on seq_nr overflowWhen submitting more than 2^32 padata objects to padata_do_serial, thecurrent sorting implementation incorrectly sorts padata objects withoverflowed seq_nr, causing them to be placed before existing objects inthe reorder list. This leads to a deadlock in the serialization processas padata_find_next cannot match padata->seq_nr and pd->processedbecause the padata instance with overflowed seq_nr will be selectednext.To fix this, we use an unsigned integer wrap around to correctly sortpadata objects in scenarios with integer overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cxgb4: Added NULL check for lookup_atidThe lookup_atid() function can return NULL if the ATID isinvalid or does not exist in the identifier table, whichcould lead to dereferencing a null pointer without acheck in the `act_establish()` and `act_open_rpl()` functions.Add a NULL check to prevent null pointer dereferencing.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: fix possible lkb_resource null dereferenceThis patch fixes a possible null pointer dereference when this function iscalled from request_lock() as lkb->lkb_resource is not assigned yet,only after validate_lock_args() by calling attach_lkb(). Another issueis that a resource name could be a non printable bytearray and we cannotassume to be ASCII coded.The log functionality is probably never being hit when DLM is used innormal way and no debug logging is enabled. The null pointer dereferencecan only occur on a new created lkb that does not have the resourceassigned yet, it probably never hits the null pointer dereference but weshould be sure that other changes might not change this behaviour and weactually can hit the mentioned null pointer dereference.In this patch we just drop the printout of the resource name, the lkb idis enough to make a possible connection to a resource name if thisexists.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-48881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: revert replacing IS_ERR_OR_NULL with IS_ERR againCommit 028ddcac477b ("bcache: Remove unnecessary NULL point check innode allocations") leads a NULL pointer deference in cache_set_flush().1721 if (!IS_ERR_OR_NULL(c->root))1722 list_add(&c->root->list, &c->btree_cache);>From the above code in cache_set_flush(), if previous registration codefails before allocating c->root, it is possible c->root is NULL as whatit is initialized. __bch_btree_node_alloc() never returns NULL butc->root is possible to be NULL at above line 1721.This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Clean up TPM space after command failuretpm_dev_transmit prepares the TPM space before attempting commandtransmission. However if the command fails no rollback of thispreparation is done. This can result in transient handles being leakedif the device is subsequently closed with no further commands performed.Fix this by flushing the space in the event of command transmissionfailure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()The kref_put() function will call nport->release if the refcount drops tozero. The nport->release release function is _efc_nport_free() which frees"nport". But then we dereference "nport" on the next line which is a useafter free. Re-order these lines to avoid the use after free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()Since commit 3f8ca2e115e5 ("vhost/scsi: Extract common handling codefrom control queue handler") a null pointer dereference bug can betriggered when guest sends an SCSI AN request.In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with`&v_req.tmf.lun[1]` within a switch-case block and is then passed tovhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, fora `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` isset to NULL in this branch. Later, in vhost_scsi_get_req(),`vc->target` is dereferenced without being checked, leading to a nullpointer dereference bug. This bug can be triggered from guest.When this bug occurs, the vhost_worker process is killed while holding`vq->mutex` and the corresponding tpg will remain occupiedindefinitely.Below is the KASAN report:Oops: general protection fault, probably for non-canonical address0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vhost_scsi_get_req+0x165/0x3a0Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 0048 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b604 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00RSP: 0018:ffff888017affb50 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350... ---[ end trace 0000000000000000 ]---Let's add a check in vhost_scsi_get_req.[whitespace fixes]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: update orig_path in ext4_find_extent()In ext4_find_extent(), if the path is not big enough, we free it and set*orig_path to NULL. But after reallocating and successfully initializingthe path, we don't update *orig_path, in which case the caller gets avalid path but a NULL ppath, and this may cause a NULL pointer dereferenceor a path memory leak. For example:ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference!==================================================================BUG: kernel NULL pointer dereference, address: 0000000000000010CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847RIP: 0010:ext4_split_extent_at+0x6d/0x560Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0[...]==================================================================Therefore, *orig_path is updated when the extent lookup succeeds, so thatthe caller can safely use path or *ppath.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49882 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix double brelse() the buffer of the extents pathIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has beenreleased, otherwise it may be released twice. An example of what triggersthis is as follows: split2 map split1|--------|-------|--------|ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twiceFinally got the following WARRNING when removing the buffer from lru:============================================VFS: brelse: Trying to free free bufferWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716RIP: 0010:__brelse+0x58/0x90Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70[...]============================================

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: aovid use-after-free in ext4_ext_insert_extent()As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path isreallocated in ext4_ext_create_new_leaf(), we'll use the stale path andcause UAF. Below is a sample trace with dummy values:ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr==================================================================BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800[...]Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700[...]==================================================================So use *ppath to update the path to avoid the above problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49886 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bugAttaching SST PCI device to VM causes "BUG: KASAN: slab-out-of-bounds".kasan report:[ 19.411889] ==================================================================[ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113[ 19.417368][ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10[ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022[ 19.422687] Call Trace:[ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80[ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.428694] print_report+0x19d/0x52e[ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10[ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.433539] kasan_report+0xf0/0x170[ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common][ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10[ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common][ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common][ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360[ 19.444797] cpuhp_invoke_callback+0x221/0xec0[ 19.446337] cpuhp_thread_fun+0x21b/0x610[ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10[ 19.449354] smpboot_thread_fn+0x2e7/0x6e0[ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10[ 19.452405] kthread+0x29c/0x350[ 19.453817] ? __pfx_kthread+0x10/0x10[ 19.455253] ret_from_fork+0x31/0x70[ 19.456685] ? __pfx_kthread+0x10/0x10[ 19.458114] ret_from_fork_asm+0x1a/0x30[ 19.459573] [ 19.460853][ 19.462055] Allocated by task 1198:[ 19.463410] kasan_save_stack+0x30/0x50[ 19.464788] kasan_save_track+0x14/0x30[ 19.466139] __kasan_kmalloc+0xaa/0xb0[ 19.467465] __kmalloc+0x1cd/0x470[ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common][ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr][ 19.471670] do_one_initcall+0xa4/0x380[ 19.472903] do_init_module+0x238/0x760[ 19.474105] load_module+0x5239/0x6f00[ 19.475285] init_module_from_file+0xd1/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.476506] idempotent_init_module+0x23b/0x650[ 19.477725] __x64_sys_finit_module+0xbe/0x130[ 19.478920] do_syscall_64+0x82/0x160[ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 19.481292][ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512[ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200)[ 19.487447][ 19.488328] The buggy address belongs to the physical page:[ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60[ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0[ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)[ 19.493914] page_type: 0xffffffff()[ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001[ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000[ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff[ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000[ 19.503784] page dumped because: k---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49890 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: ensure the fw_info is not null before using itThis resolves the dereference null return value warningreported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata pathsWhen the HBA is undergoing a reset or is handling an errata event, NULL ptrdereference crashes may occur in routines such aslpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), orlpfc_abort_handler().Add NULL ptr checks before dereferencing hdwq pointers that may have beenfreed due to operations colliding with a reset or errata event handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize get_bytes_per_element's default to 1Variables, used as denominators and maybe not assigned to other values,should not be 0. bytes_per_element_y & bytes_per_element_c areinitialized by get_bytes_per_element() which should never return 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check stream before comparing them[WHAT & HOW]amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It isnecessary to check for null before dereferencing them.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Initialize denominators' default to 1[WHAT & HOW]Variables used as denominators and maybe not assigned to other values,should not be 0. Change their default to 1 so they are never 0.This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49901 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrsThere are some cases, such as the one uncovered by Commit 46d4efcccc68("drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails")wheremsm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL);is called on gpu->pdev == NULL, as the GPU device has not been fullyinitialized yet.Turns out that there's more than just the aforementioned path thatcauses this to happen (e.g. the case when there's speedbin data in thecatalog, but opp-supported-hw is missing in DT).Assigning msm_gpu->pdev earlier seems like the least painful solutionto this, therefore do so.Patchwork: https://patchwork.freedesktop.org/patch/602742/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2)This commit adds a null check for the 'afb' variable in theamdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' wasassumed to be null, but was used later in the code without a null check.This could potentially lead to a null pointer dereference.Changes since v1:- Moved the null check for 'afb' to the line where 'afb' is used. (Alex)Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49907 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using dc->clk_mgr[WHY & HOW]dc->clk_mgr is null checked previously in the same function, indicatingit might be null.Passing "dc" to "dc->hwss.apply_idle_power_optimizations", whichdereferences null "dc->clk_mgr". (The function pointer resolves to"dcn35_apply_idle_power_optimizations".)This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_funcThis commit adds a null check for the set_output_gamma function pointerin the dcn20_set_output_transfer_func function. Previously,set_output_gamma was being checked for null at line 1030, but then itwas being dereferenced without any null check at line 1048. This couldpotentially lead to a null pointer dereference error if set_output_gammais null.To fix this, we now ensure that set_output_gamma is not null beforedereferencing it. We do this by adding a null check for set_output_gammabefore the call to set_output_gamma at line 1048.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_streamThis commit addresses a null pointer dereference issue in the`commit_planes_for_stream` function at line 4140. The issue could occurwhen `top_pipe_to_program` is null.The fix adds a check to ensure `top_pipe_to_program` is not null beforeaccessing its stream_res. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipeThis commit addresses a null pointer dereference issue in the`dcn20_program_pipe` function. The issue could occur when`pipe_ctx->plane_state` is null.The fix adds a check to ensure `pipe_ctx->plane_state` is not nullbefore accessing. This prevents a null pointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hwThis commit addresses a potential null pointer dereference issue in the`dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or`dc->clk_mgr->funcs` is null.The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` isnot null before accessing its functions. This prevents a potential nullpointer dereference.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before multiple uses[WHAT & HOW]Poniters, such as stream_enc and dc->bw_vbios, are null checked previouslyin the same function, so Coverity warns "implies that stream_enc anddc->bw_vbios might be null". They are used multiple times in thesubsequent code and need to be checked.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49921 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before used[WHAT & HOW]Poniters, such as dc->clk_mgr, are null checked previously in the samefunction, so Coverity warns "implies that "dc->clk_mgr" might be null".As a result, these pointers need to be checked when used again.This fixes 10 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointers before using them[WHAT & HOW]These pointers are null checked previously in the same function,indicating they might be null as reported by Coverity. As a result,they need to be checked when used again.This fixes 3 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49923 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags[WHAT & HOW]"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus itcannot be a null pointer. Let's pass a valid pointer to avoid nulldereference.This fixes 2 FORWARD_NULL issues reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49929 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: avoid NULL pointer dereferenceiwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvstapointer is not NULL.It retrieves this pointer using iwl_mvm_sta_from_mac80211, which isdereferencing the ieee80211_sta pointer.If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULLpointer.Fix this by checking the sta pointer before retrieving the mvmstafrom it. If sta is not NULL, then mvmsta isn't either.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: PAD: fix crash in exit_round_robin()The kernel occasionally crashes in cpumask_clear_cpu(), which is calledwithin exit_round_robin(), because when executing clear_bit(nr, addr) withnr set to 0xffffffff, the address calculation may cause misalignment withinthe memory, leading to access to an invalid memory address.----------BUG: unable to handle kernel paging request at ffffffffe0740618 ...CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ...RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000eR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000eFS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ...CR2: ffffffffe0740618crash> dis -lr ffffffffc0726923 .../usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 1140xffffffffc0726918 : mov %r12d,%r12d/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 3250xffffffffc072691b : mov -0x3f8d7de0(,%r12,4),%eax/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 800xffffffffc0726923 : lock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14]$66 = 0xffffffffcrash> px 0xffffffffc072692c+0x19cf4$99 = 0xffffffffc0740620crash> sym 0xffffffffc0740620ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]crash> px pad_busy_cpus_bits[0]$42 = 0xfffc0----------To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before callingcpumask_clear_cpu() in exit_round_robin(), just as it is done inround_robin_cpu().[ rjw: Subject edit, avoid updates to the same value ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49939 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw89: avoid to add interface to list twice when SERIf SER L2 occurs during the WoWLAN resume flow, the add interface flowis triggered by ieee80211_reconfig(). However, due tortw89_wow_resume() return failure, it will cause the add interface flowto be executed again, resulting in a double add list and causing a kernelpanic. Therefore, we have added a check to prevent double adding of thelist.list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.------------[ cut here ]------------kernel BUG at lib/list_debug.c:37!invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021Workqueue: events_freezable ieee80211_restart_work [mac80211]RIP: 0010:__list_add_valid_or_report+0x5e/0xb0Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydevgsmi: Log Shutdown Reason 0x03---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_startIn sctp_listen_start() invoked by sctp_inet_listen(), it should set thesk_state back to CLOSED if sctp_autobind() fails due to whatever reason.Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuseis already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash willbe dereferenced as sk_state is LISTENING, which causes a crash as bind_hashis NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49946 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: do not assume bh is held in ppp_channel_bridge_input()Networking receive path is usually handled from BH handler.However, some protocols need to acquire the socket lock, andpackets might be stored in the socket backlog is the socket wasowned by a user process.In this case, release_sock(), __release_sock(), and sk_backlog_rcv()might call the sk->sk_backlog_rcv() handler in process context.sybot caught ppp was not considering this case inppp_channel_bridge_input() :WARNING: inconsistent lock state6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted--------------------------------inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304{SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK ***1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325stack backtrace:CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: add more sanity checks to qdisc_pkt_len_init()One path takes care of SKB_GSO_DODGY, assumingskb->len is bigger than hdr_len.virtio_net_hdr_to_skb() does not fully dissect TCP headers,it only make sure it is at least 20 bytes.It is possible for an user to provide a malicious 'GSO' packet,total length of 80 bytes.- 20 bytes of IPv4 header- 60 bytes TCP header- a small gso_size like 8virtio_net_hdr_to_skb() would declare this packet as a normalGSO packet, because it would see 40 bytes of payload,bigger than gso_size.We need to make detect this case to not underflowqdisc_skb_cb(skb)->pkt_len.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49949 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: avoid potential underflow in qdisc_pkt_len_init() with UFOAfter commit 7c6d2ecbda83 ("net: be more gentle about silly gsorequests coming from user") virtio_net_hdr_to_skb() had sanity checkto detect malicious attempts from user space to cook a bad GSO packet.Then commit cf9acc90c80ec ("net: virtio_net_hdr_to_skb: counttransport header in UFO") while fixing one issue, allowed user spaceto cook a GSO packet with the following characteristic :IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.When this packet arrives in qdisc_pkt_len_init(), we end upwith hdr_len = 28 (IPv4 header + UDP header), matching skb->lenThen the following sets gso_segs to 0 :gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size);Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;This leads to the following crash in fq_codel [1]qdisc_pkt_len_init() is best effort, we only want an estimationof the bytes sent on the wire, not crashing the kernel.This patch is fixing this particular issue, a following oneadds more sanity checks for another potential bug.[1][ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 70.724561] #PF: supervisor read access in kernel mode[ 70.724561] #PF: error_code(0x0000) - not-present page[ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0[ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI[ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991[ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49All code======== 0: 24 08 and $0x8,%al 2: 49 c1 e1 06 shl $0x6,%r9 6: 44 89 7c 24 18 mov %r15d,0x18(%rsp) b: 45 31 ed xor %r13d,%r13d e: 45 31 c0 xor %r8d,%r8d 11: 31 ff xor %edi,%edi 13: 89 44 24 14 mov %eax,0x14(%rsp) 17: 4c 03 8b 90 01 00 00 add 0x190(%rbx),%r9 1e: eb 04 jmp 0x24 20: 39 ca cmp %ecx,%edx 22: 73 37 jae 0x5b 24: 4d 8b 39 mov (%r9),%r15 27: 83 c7 01 add $0x1,%edi 2a:* 49 8b 17 mov (%r15),%rdx <-- trapping instruction 2d: 49 89 11 mov %rdx,(%r9) 30: 41 8b 57 28 mov 0x28(%r15),%edx 34: 45 8b 5f 34 mov 0x34(%r15),%r11d 38: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 3f: 49 rex.WBCode starting with the faulting instruction=========================================== 0: 49 8b 17 mov (%r15),%rdx 3: 49 89 11 mov %rdx,(%r9) 6: 41 8b 57 28 mov 0x28(%r15),%edx a: 45 8b 5f 34 mov 0x34(%r15),%r11d e: 49 c7 07 00 00 00 00 movq $0x0,(%r15) 15: 49 rex.WB[ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202[ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000[ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001[ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000[ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58[ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000[ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000[ 70.724561] CS: 0010 DS: 0000 ES: 0000 C---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49952 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prevent nf_skb_duplicated corruptionsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could writeper-cpu variable nf_skb_duplicated in an unsafe way [1].Disabling preemption as hinted by the splat is not enough,we have to disable soft interrupts as well.[1]BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f4ce4f7def9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49954 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Replace pointless WARN_ON() in static_call_module_notify()static_call_module_notify() triggers a WARN_ON(), when memory allocationfails in __static_call_add_module().That's not really justified, because the failure case must be correctlyhandled by the well known call chain and the error code is passedthrough to the initiating userspace application.A memory allocation fail is not a fatal problem, but the WARN_ON() takesthe machine out when panic_on_warn is set.Replace it with a pr_warn().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49955 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: battery: Fix possible crash when unregistering a battery hookWhen a battery hook returns an error when adding a new battery, thenthe battery hook is automatically unregistered.However the battery hook provider cannot know that, so it will latercall battery_hook_unregister() on the already unregistered batteryhook, resulting in a crash.Fix this by using the list head to mark already unregistered batteryhooks as already being unregistered so that they can be ignored bybattery_hook_unregister().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix null-ptr-deref when journal load failed.During the mounting process, if journal_reset() fails because of too shortjournal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() callsjbd2_journal_flush()->jbd2_cleanup_journal_tail()->__jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail()->lock_buffer(journal->j_sb_buffer), resulting in a null-pointerdereference error.To resolve this issue, we should check the JBD2_LOADED flag to ensure thejournal was properly loaded. Additionally, use journal instead ofosb->journal directly to simplify the code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49958 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: reserve space for inline xattr before attaching reflink treeOne of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting,the fsck -fn output showed the below corruption[EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record,but fsck believes the largest valid value is 227. Clamp the next record value? nThe stat output from the debugfs.ocfs2 showed the following corruptionwhere the "Next Free Rec:" had overshot the "Count:" in the root metadatablock. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... .......The issue was in the reflink workfow while reserving space for inlinexattr. The problematic function is ocfs2_reflink_xattr_inline(). By thetime this function is called the reflink tree is already recreated at thedestination inode from the source inode. At this point, this functionreserves space for inline xattrs at the destination inode without evenchecking if there is space at the root metadata block. It simply reducesthe l_count from 243 to 227 thereby making space of 256 bytes for inlinexattr whereas the inode already has extents beyond this index (in thiscase up to 230), thereby causing corruption.The fix for this is to reserve space for inline metadata at the destinationinode before the reflink tree gets recreated. The customer has verified thefix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns errorIn __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail()to recover some journal space. But if an error occurs while executingjbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for freespace right away, we try other branches, and if j_committing_transactionis NULL (i.e., the tid is 0), we will get the following complain:============================================JBD2: I/O error when updating journal superblock for sdd-8.__jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available__jbd2_log_wait_for_space: no way to get more journal space in sdd-8------------[ cut here ]------------WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0Modules linked in:CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70[...]============================================So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing toclean up at the moment, continue to try to reclaim free space in other ways.Note that this fix relies on commit 6f6a6fda2945 ("jbd2: fix ocfs2 corruptwhen updating journal superblock fails") to make jbd2_cleanup_journal_tailreturn the correct error code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49962 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package()ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will causeNULL pointer dereference later.[ rjw: Subject and changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49963 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mailbox: bcm2835: Fix timeout during suspend modeDuring noirq suspend phase the Raspberry Pi power driver suffer offirmware property timeouts. The reason is that the IRQ of the underlyingBCM2835 mailbox is disabled and rpi_firmware_property_list() will alwaysrun into a timeout [1].Since the VideoCore side isn't consider as a wakeup source, set theIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabledduring suspend-resume cycle.[1]PM: late suspend of devices complete after 1.754 msecsWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22cFirmware transaction 0x00028001 timeoutModules linked in:CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17Hardware name: BCM2835Call trace:unwind_backtrace from show_stack+0x18/0x1cshow_stack from dump_stack_lvl+0x34/0x44dump_stack_lvl from __warn+0x88/0xec__warn from warn_slowpath_fmt+0x7c/0xb0warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22crpi_firmware_property_list from rpi_firmware_property+0x68/0x8crpi_firmware_property from rpi_firmware_set_power+0x54/0xc0rpi_firmware_set_power from _genpd_power_off+0xe4/0x148_genpd_power_off from genpd_sync_power_off+0x7c/0x11cgenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0genpd_finish_suspend from dpm_run_callback+0x78/0xd0dpm_run_callback from device_suspend_noirq+0xc0/0x238device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5acsuspend_devices_and_enter from pm_suspend+0x254/0x2e4pm_suspend from state_store+0xa8/0xd4state_store from kernfs_fop_write_iter+0x154/0x1a0kernfs_fop_write_iter from vfs_write+0x12c/0x184vfs_write from ksys_write+0x78/0xc0ksys_write from ret_fast_syscall+0x0/0x54Exception stack(0xcc93dfa8 to 0xcc93dff0)[...]PM: noirq suspend of devices complete after 3095.584 msecs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49965 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: remove unreasonable unlock in ocfs2_read_blocksPatch series "Misc fixes for ocfs2_read_blocks", v5.This series contains 2 fixes for ocfs2_read_blocks(). The first patch fixthe issue reported by syzbot, which detects bad unlock balance inocfs2_read_blocks(). The second patch fixes an issue reported by HemingZhao when reviewing above fix.This patch (of 2):There was a lock release before exiting, so remove the unreasonable unlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49966 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: cancel dqi_sync_work before freeing oinfoocfs2_global_read_info() will initialize and schedule dqi_sync_work at theend, if error occurs after successfully reading global quota, it willtrigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled:ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16cThis reports that there is an active delayed work when freeing oinfo inerror handling, so cancel dqi_sync_work first. BTW, return status insteadof -1 when .read_file_info fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49967 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:r8169: add tally counter fields added with RTL8125RTL8125 added fields to the tally counter, what may result in the chipdma'ing these new fields to unallocated memory. Therefore make surethat the allocated memory area is big enough to hold all of thetally counter values, even if we use only parts of it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobes: fix kernel info leak via "[uprobes]" vmaxol_add_vma() maps the uninitialized page allocated by __create_xol_area()into userspace. On some architectures (x86) this memory is readable evenwithout VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ,although this doesn't really matter, debugger can read this memory anyway.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gso: fix udp gso fraglist segmentation after pull from frag_listDetect gso fraglist skbs with corrupted geometry (see below) andpass these to skb_segment instead of skb_segment_list, as the firstcan segment them correctly.Valid SKB_GSO_FRAGLIST skbs- consist of two or more segments- the head_skb holds the protocol headers plus first gso_size- one or more frag_list skbs hold exactly one segment- all but the last must be gso_sizeOptional datapath hooks such as NAT and BPF (bpf_skb_pull_data) canmodify these skbs, breaking these invariants.In extreme cases they pull all data into skb linear. For UDP, thiscauses a NULL ptr deref in __udpv4_gso_segment_list_csum atudp_hdr(seg->next)->dest.Detect invalid geometry due to pull, by checking head_skb size.Don't just drop, as this may blackhole a destination. Convert to beable to pass to regular skb_segment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49983 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-freeWhen calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(),the 'ppath' is updated but it is the 'path' that is freed, thus potentiallytriggering a double-free in the following process:ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!!So drop the unnecessary ppath and use path directly to avoid this problem.And use ext4_find_extent() directly to update path, avoiding unnecessarymemory allocation and freeing. Also, propagate the error returned byext4_find_extent() instead of using strange error codes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resumeIn case there is any sort of clock controller attached to this I2C buscontroller, for example Versaclock or even an AIC32x4 I2C codec, thenan I2C transfer triggered from the clock controller clk_ops .preparecallback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.This is because the clock controller first grabs the prepare_lock mutexand then performs the prepare operation, including its I2C access. TheI2C access resumes this I2C bus controller via .runtime_resume callback,which calls clk_prepare_enable(), which attempts to grab the prepare_lockmutex again and deadlocks.Since the clock are already prepared since probe() and unprepared inremove(), use simple clk_enable()/clk_disable() calls to enable anddisable the clock on runtime suspend and resume, to avoid hitting theprepare_lock mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49994 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix integer overflow in BLKSECDISCARDI independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard()but for secure erase.Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r);will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix buffer overflow when parsing NFS reparse pointsReparseDataLength is sum of the InodeType size and DataBuffer size.So to get DataBuffer size it is needed to subtract InodeType's size fromReparseDataLength.Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBufferat position after the end of the buffer because it does not subtractInodeType size from the length. Fix this problem and correctly subtractvariable len.Member InodeType is present only when reparse buffer is large enough. Checkfor ReparseDataLength before accessing InodeType to prevent another invalidmemory access.Major and minor rdev values are present also only when reparse buffer islarge enough. Check for reparse buffer size before calling reparse_mkdev().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()In mlx5e_tir_builder_alloc() kvzalloc() may return NULLwhich is dereferenced on the next line in a referenceto the modify field.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix error path in multi-packet WQE transmitRemove the erroneous unmap in case no DMA mapping was establishedThe multi-packet WQE transmit code attempts to obtain a DMA mapping forthe skb. This could fail, e.g. under memory pressure, when the IOMMUdriver just can't allocate more memory for page tables. While the codetries to handle this in the path below the err_unmap label it erroneouslyunmaps one entry from the sq's FIFO list of active mappings. Since thecurrent map attempt failed this unmap is removing some random DMA mappingthat might still be required. If the PCI function now presents that IOVA,the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCIfunction in error state.The erroneous behavior was seen in a stress-test environment that createdmemory pressure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:static_call: Handle module init failure correctly in static_call_del_module()Module insertion invokes static_call_add_module() to initialize the staticcalls in a module. static_call_add_module() invokes __static_call_init(),which allocates a struct static_call_mod to either encapsulate the built-instatic call sites of the associated key into it so further modules can beadded or to append the module to the module chain.If that allocation fails the function returns with an error code and themodule core invokes static_call_del_module() to clean up eventually addedstatic_call_mod entries.This works correctly, when all keys used by the module were converted overto a module chain before the failure. If not then static_call_del_module()causes a #GP as it blindly assumes that key::mods points to a valid structstatic_call_mod.The problem is that key::mods is not a individual struct member of structstatic_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; };key::sites is a pointer to the list of built-in usage sites of the staticcall. The type of the pointer is differentiated by bit 0. A mods pointerhas the bit clear, the sites pointer has the bit set.As static_call_del_module() blidly assumes that the pointer is a validstatic_call_mod type, it fails to check for this failure case anddereferences the pointer to the list of built-in call sites, which isobviously bogus.Cure it by checking whether the key has a sites or a mods pointer.If it's a sites pointer then the key is not to be touched. As the sites arewalked in the same order as in __static_call_init() the site walk can beterminated because all subsequent sites have not been touched by the initcode due to the error exit.If it was converted before the allocation fail, then the inner loop whichsearches for a module match will find nothing.A fail in the second allocation in __static_call_init() is harmless anddoes not require special treatment. The first allocation succeeded andconverted the key to a module chain. That first entry has mod::mod == NULLand mod::next == NULL, so the inner loop of static_call_del_module() willneither find a module match nor a module chain. The next site in the walkwas either already converted, but can't match the module, or it will exitthe outer loop because it has a static_call_site pointer and not astatic_call_mod pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50013 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix memory leak in exfat_load_bitmap()If the first directory entry in the root directory is not a bitmapdirectory entry, 'bh' will not be released and reassigned, whichwill cause a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix access to uninitialised lock in fc replay pathThe following kernel trace can be triggered with fstest generic/629 whenexecuted against a filesystem with fast-commit feature enabled:INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn't initialize this object before use?turning off the locking correctness validator.CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180...In the replay path there's an attempt to lock sbi->s_bdev_wb_lock infunction ext4_check_bdev_write_error(). Unfortunately, at this point thisspinlock has not been initialized yet. Moving it's initialization to anearlier point in __ext4_fill_super() fixes this splat.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50015 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: dax: fix overflowing extents beyond inode size when partially writingThe dax_iomap_rw() does two things in each iteration: map written blocksand copy user data to blocks. If the process is killed by user(See signalhandling in dax_iomap_iter()), the copied data will be returned and addedon inode size, which means that the length of written extents may exceedthe inode size, then fsck will fail. An example is given as:dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2Mfsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix?Fix the problem by truncating extents if the written length is smallerthan expected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:kthread: unpark only parked kthreadCalling into kthread unparking unconditionally is mostly harmless whenthe kthread is already unparked. The wake up is then simply ignoredbecause the target is not in TASK_PARKED state.However if the kthread is per CPU, the wake up is preceded by a callto kthread_bind() which expects the task to be inactive and inTASK_PARKED state, which obviously isn't the case if it is unparked.As a result, calling kthread_stop() on an unparked per-cpu kthreadtriggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Fix this with skipping unecessary unparking while stopping a kthread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix an unsafe loop on the listThe kernel may crash when deleting a genetlink family if there are stilllisteners for that family:Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace:__netlink_clear_multicast_users+0x74/0xc0genl_unregister_family+0xd4/0x2d0Change the unsafe loop on the list to a safe one, because inside theloop there is an element removal from this list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: core: Reference count the zone in thermal_zone_get_by_id()There are places in the thermal netlink code where nothing preventsthe thermal zone object from going away while being accessed after ithas been returned by thermal_zone_get_by_id().To address this, make thermal_zone_get_by_id() get a reference on thethermal zone device object to be returned with the help of get_device(),under thermal_list_lock, and adjust all of its callers to this changewith the help of the cleanup.h infrastructure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slip: make slhc_remember() more robust against malicious packetssyzbot found that slhc_remember() was missing checks againstmalicious packets [1].slhc_remember() only checked the size of the packet was at least 20,which is not good enough.We need to make sure the packet includes the IPv4 and TCP headerthat are supposed to be carried.Add iph and th pointers to make the code more readable.[1]BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50036 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: do not delay dst_entries_add() in dst_release()dst_entries_add() uses per-cpu data that might be freed at netnsdismantle from ip6_route_net_exit() calling dst_entries_destroy()Before ip6_route_net_exit() can be called, we release allthe dsts associated with this netns, via calls to dst_release(),which waits an rcu grace period before calling dst_destroy()dst_entries_add() use in dst_destroy() is racy, becausedst_entries_destroy() could have been called already.Decrementing the number of dsts must happen sooner.Notes:1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this.2) There is also discussion about removing this count of dst, which might happen in future kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: xtables: avoid NFPROTO_UNSPEC where neededsyzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packetprocessing. As this is only useful to restrict locally terminatingTCP/UDP traffic, register this for ipv4 and ipv6 family only.Pablo points out that this is a general issue, direct users of theset/getsockopt interface can call into targets/matches that were onlyintended for use with ip(6)tables.Check all UNSPEC matches and targets for similar issues:- matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area.- targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE.Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, asthey are provided for use by ip(6)tables.The MARK target is also used by arptables, so register for NFPROTO_ARP too.While at it, bail out if connbytes fails to enable the correspondingconntrack family.This change passes the selftests in iptables.git.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50039 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: accept TCA_STAB only for root qdiscMost qdiscs maintain their backlog using qdisc_pkt_len(skb)on the assumption it is invariant between the enqueue()and dequeue() handlers.Unfortunately syzbot can crash a host rather easily usinga TBF + SFQ combination, with an STAB on SFQ [1]We can't support TCA_STAB on arbitrary level, this wouldrequire to maintain per-qdisc storage.[1][ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 88.798611] #PF: supervisor read access in kernel mode[ 88.799014] #PF: error_code(0x0000) - not-present page[ 88.799506] PGD 0 P4D 0[ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI[ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117[ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00All code======== 0: 0f b7 50 12 movzwl 0x12(%rax),%edx 4: 48 8d 04 d5 00 00 00 lea 0x0(,%rdx,8),%rax b: 00 c: 48 89 d6 mov %rdx,%rsi f: 48 29 d0 sub %rdx,%rax 12: 48 8b 91 c0 01 00 00 mov 0x1c0(%rcx),%rdx 19: 48 c1 e0 03 shl $0x3,%rax 1d: 48 01 c2 add %rax,%rdx 20: 66 83 7a 1a 00 cmpw $0x0,0x1a(%rdx) 25: 7e c0 jle 0xffffffffffffffe7 27: 48 8b 3a mov (%rdx),%rdi 2a:* 4c 8b 07 mov (%rdi),%r8 <-- trapping instruction 2d: 4c 89 02 mov %r8,(%rdx) 30: 49 89 50 08 mov %rdx,0x8(%r8) 34: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 3b: 00 3c: 48 rex.W 3d: c7 .byte 0xc7 3e: 07 (bad) ...Code starting with the faulting instruction=========================================== 0: 4c 8b 07 mov (%rdi),%r8 3: 4c 89 02 mov %r8,(%rdx) 6: 49 89 50 08 mov %rdx,0x8(%r8) a: 48 c7 47 08 00 00 00 movq $0x0,0x8(%rdi) 11: 00 12: 48 rex.W 13: c7 .byte 0xc7 14: 07 (bad) ...[ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206[ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800[ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000[ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f[ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140[ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac[ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000[ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0[ 88.808165] Call Trace:[ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434)[ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715)[ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539)[ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)[ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq[ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq[ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50041 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix macvlan leak by synchronizing access to mac_filter_hashThis patch addresses a macvlan leak issue in the i40e driver caused byconcurrent access to vsi->mac_filter_hash. The leak occurs when multiplethreads attempt to modify the mac_filter_hash simultaneously, leading toinconsistent state and potential memory leaks.To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroingvf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock),ensuring atomic operations and preventing concurrent access.Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) ini40e_add_mac_filter() to help catch similar issues in the future.Reproduction steps:1. Spawn VFs and configure port vlan on them.2. Trigger concurrent macvlan operations (e.g., adding and deleting portvlan and/or mac filters).3. Observe the potential memory leak and inconsistent state in the mac_filter_hash.This synchronization ensures the integrity of the mac_filter_hash and preventsthe described leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_changerfcomm_sk_state_change attempts to use sock_lock so it must never becalled with it locked but rfcomm_sock_ioctl always attempt to lock itcausing the following trace:======================================================WARNING: possible circular locking dependency detected6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted------------------------------------------------------syz-executor386/5093 is trying to acquire lock:ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline]ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73but task is already holding lock:ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50045 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: br_netfilter: fix panic with metadata_dst skbFix a kernel panic in the br_netfilter module when sending untaggedtraffic via a VxLAN device.This happens during the check for fragmentation in br_nf_dev_queue_xmit.It is dependent on:1) the br_netfilter module being loaded;2) net.bridge.bridge-nf-call-iptables set to 1;3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port;4) untagged frames with size higher than the VxLAN MTU forwarded/floodedWhen forwarding the untagged packet to the VxLAN bridge port, beforethe netfilter hooks are called, br_handle_egress_vlan_tunnel is called andchanges the skb_dst to the tunnel dst. The tunnel_dst is a metadata typeof dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL.Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a checkfor frames that needs to be fragmented: frames with higher MTU than theVxLAN device end up calling br_nf_ip_fragment, which in turns callip_skb_dst_mtu.The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dstwith valid dst->dev, thus the crash.This case was never supported in the first place, so drop the packetinstead.PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data.[ 176.291791] Unable to handle kernel NULL pointer dereference atvirtual address 0000000000000110[ 176.292101] Mem abort info:[ 176.292184] ESR = 0x0000000096000004[ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits[ 176.292530] SET = 0, FnV = 0[ 176.292709] EA = 0, S1PTW = 0[ 176.292862] FSC = 0x04: level 0 translation fault[ 176.293013] Data abort info:[ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000[ 176.294166] [0000000000000110] pgd=0000000000000000,p4d=0000000000000000[ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel vethbr_netfilter bridge stp llc ipv6 crct10dif_ce[ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted6.8.0-rc3-g5b3fbd61b9d1 #2[ 176.296314] Hardware name: linux,dummy-virt (DT)[ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBSBTYPE=--)[ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter][ 176.297636] sp : ffff800080003630[ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27:ffff6828c49ad9f8[ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24:00000000000003e8[ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21:ffff6828c3b16d28[ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18:0000000000000014[ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15:0000000095744632[ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12:ffffb7e137926a70[ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 :0000000000000000[ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 :f20e0100bebafeca[ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 :0000000000000000[ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 :ffff6828c7f918f0[ 176.300889] Call trace:[ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter][ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter][ 176.301703] nf_hook_slow+0x48/0x124[ 176.302060] br_forward_finish+0xc8/0xe8 [bridge][ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter][ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter][ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter][ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter][ 176.303359] nf_hook_slow+0x48/0x124[ 176.303---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50046 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()On the node of an NFS client, some files saved in the mountpoint of theNFS server were copied to another location of the same NFS server.Accidentally, the nfs42_complete_copies() got a NULL-pointer dereferencecrash with the following syslog:[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058[232066.588586] Mem abort info:[232066.588701] ESR = 0x0000000096000007[232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits[232066.589084] SET = 0, FnV = 0[232066.589216] EA = 0, S1PTW = 0[232066.589340] FSC = 0x07: level 3 translation fault[232066.589559] Data abort info:[232066.589683] ISV = 0, ISS = 0x00000007[232066.589842] CM = 0, WnR = 0[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000[232066.590757] Internal error: Oops: 96000007 [#1] SMP[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2[232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1[232066.597356] Hardware name: Great Wall .\x93\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4][232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4][232066.598595] sp : ffff8000f568fc70[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6[232066.600498] x11: 00000000000000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check null pointer before dereferencing se[WHAT & HOW]se is null checked previously in the same function, indicatingit might be null; therefore, it must be checked when used again.This fixes 1 FORWARD_NULL issue reported by Coverity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:driver core: bus: Fix double free in driver API bus_register()For bus_register(), any error which happens after kset_register() willcause that @priv are freed twice, fixed by setting @priv with NULL afterthe first free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: protect uart_port_dtr_rts() in uart_shutdown() tooCommit af224ca2df29 (serial: core: Prevent unsafe uart port access, part3) added few uport == NULL checks. It added one to uart_shutdown(), sothe commit assumes, uport can be NULL in there. But right after thatprotection, there is an unprotected "uart_port_dtr_rts(uport, false);"call. That is invoked only if HUPCL is set, so I assume that is thereason why we do not see lots of these reports.Or it cannot be NULL at this point at all for some reason :P.Until the above is investigated, stay on the safe side and move thisdereference to the if too.I got this inconsistency from Coverity under CID 1585130. Thanks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50061 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race ConditionIn the cdns_i3c_master_probe function, &master->hj_work is bound withcdns_i3c_master_hj. And cdns_i3c_master_interrupt can callcnds_i3c_master_demux_ibis function to start the work.If we remove the module which will call cdns_i3c_master_remove tomake cleanup, it will free master->base through i3c_master_unregisterwhile the work mentioned above will be used. The sequence of operationsthat may lead to a UAF bug is as follows:CPU0 CPU1 | cdns_i3c_master_hjcdns_i3c_master_remove |i3c_master_unregister(&master->base) |device_unregister(&master->dev) |device_release |//free master->base | | i3c_master_do_daa(&master->base) | //use master->baseFix it by ensuring that the work is canceled before proceeding withthe cleanup in cdns_i3c_master_remove.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rtrs-srv: Avoid null pointer deref during path establishmentFor RTRS path establishment, RTRS client initiates and completes con_numof connections. After establishing all its connections, the informationis exchanged between the client and server through the info_req message.During this exchange, it is essential that all connections have beenestablished, and the state of the RTRS srv path is CONNECTED.So add these sanity checks, to make sure we detect and abort process inerror scenarios to avoid null pointer deref.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50067 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uprobe: avoid out-of-bounds memory access of fetching argsUprobe needs to fetch args into a percpu buffer, and then copy to ringbuffer to avoid non-atomic context problem.Sometimes user-space strings, arrays can be very large, but the size ofpercpu buffer is only page size. And store_trace_args() won't checkwhether these data exceeds a single page or not, caused out-of-boundsmemory access.It could be reproduced by following steps:1. build kernel with CONFIG_KASAN enabled2. save follow program as test.c```\#include \#include \#include // If string length large than MAX_STRING_SIZE, the fetch_store_strlen()// will return 0, cause __get_data_size() return shorter size, and// store_trace_args() will not trigger out-of-bounds access.// So make string length less than 4096.\#define STRLEN 4093void generate_string(char *str, int n){ int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0';}void print_string(char *str){ printf("%s\n", str);}int main(){ char tmp[STRLEN]; generate_string(tmp, STRLEN); print_string(tmp); return 0;}```3. compile program`gcc -o test test.c`4. get the offset of `print_string()````objdump -t test | grep -w print_string0000000000401199 g F .text 000000000000001b print_string```5. configure uprobe with offset 0x1199```off=0x1199cd /sys/kernel/debug/tracing/echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobe_eventsecho 1 > events/uprobes/enableecho 1 > tracing_on```6. run `test`, and kasan will report error.==================================================================BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014Call Trace: dump_stack_lvl+0x55/0x70 print_address_description.constprop.0+0x27/0x310 kasan_report+0x10f/0x120 ? strncpy_from_user+0x1d6/0x1f0 strncpy_from_user+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 process_fetch_insn+0xb26/0x1470 ? __pfx_process_fetch_insn+0x10/0x10 ? _raw_spin_lock+0x85/0xe0 ? __pfx__raw_spin_lock+0x10/0x10 ? __pte_offset_map+0x1f/0x2d0 ? unwind_next_frame+0xc5f/0x1f80 ? arch_stack_walk+0x68/0xf0 ? is_bpf_text_address+0x23/0x30 ? kernel_text_address.part.0+0xbb/0xd0 ? __kernel_text_address+0x66/0xb0 ? unwind_get_return_address+0x5e/0xa0 ? __pfx_stack_trace_consume_entry+0x10/0x10 ? arch_stack_walk+0xa2/0xf0 ? _raw_spin_lock_irqsave+0x8b/0xf0 ? __pfx__raw_spin_lock_irqsave+0x10/0x10 ? depot_alloc_stack+0x4c/0x1f0 ? _raw_spin_unlock_irqrestore+0xe/0x30 ? stack_depot_save_flags+0x35d/0x4f0 ? kasan_save_stack+0x34/0x50 ? kasan_save_stack+0x24/0x50 ? mutex_lock+0x91/0xe0 ? __pfx_mutex_lock+0x10/0x10 prepare_uprobe_buffer.part.0+0x2cd/0x500 uprobe_dispatcher+0x2c3/0x6a0 ? __pfx_uprobe_dispatcher+0x10/0x10 ? __kasan_slab_alloc+0x4d/0x90 handler_chain+0xdd/0x3e0 handle_swbp+0x26e/0x3d0 ? __pfx_handle_swbp+0x10/0x10 ? uprobe_pre_sstep_notifier+0x151/0x1b0 irqentry_exit_to_user_mode+0xe2/0x1b0 asm_exc_int3+0x39/0x40RIP: 0033:0x401199Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ceRSP: 002b:00007ffdf00576a8 EFLAGS: 00000206RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 This commit enforces the buffer's maxlen less than a page-size to avoidstore_trace_args() out-of-memory access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:parport: Proper fix for array out-of-bounds accessThe recent fix for array out-of-bounds accesses replaced sprintf()calls blindly with snprintf(). However, since snprintf() returns thewould-be-printed size, not the actually output size, the lengthcalculation can still go over the given limit.Use scnprintf() instead of snprintf(), which returns the actuallyoutput letters, for addressing the potential out-of-bounds accessproperly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: intel: int340x: processor: Fix warning during module unloadThe processor_thermal driver uses pcim_device_enable() to enable a PCIdevice, which means the device will be automatically disabled on driverdetach. Thus there is no need to call pci_disable_device() again on it.With recent PCI device resource management improvements, e.g. commitf748a07a0b64 ("PCI: Remove legacy pcim_release()"), this problem isexposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]---Remove the excess pci_disable_device() calls.[ rjw: Subject and changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mad: Improve handling of timed out WRs of mad agentCurrent timeout handler of mad agent acquires/releases mad_agent_privlock for every timed out WRs. This causes heavy locking contentionwhen higher no. of WRs are to be handled inside timeout handler.This leads to softlockup with below trace in some use cases whererdma-cm path is used to establish connection between peer nodesTrace:----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRsand invoke send handler post creating the list. The new method acquires/releases lock once to fetch the list and hence helps to reduce lockingcontetiong when processing higher no. of WRs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy errorThe `nouveau_dmem_copy_one` function ensures that the copy push command issent to the device firmware but does not track whether it was executedsuccessfully.In the case of a copy error (e.g., firmware or hardware failure), thecopy push command will be sent via the firmware channel, and`nouveau_dmem_copy_one` will likely report success, leading to the`migrate_to_ram` function returning a dirty HIGH_USER page to the user.This can result in a security vulnerability, as a HIGH_USER page that maycontain sensitive or corrupted data could be returned to the user.To prevent this vulnerability, we allocate a zero page. Thus, in case ofan error, a non-dirty (zero) page will be returned to the user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut downThere is a history of deadlock if reboot is performed at the beginningof booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFSshutdown, and at that time the audio driver was waiting onblk_mq_submit_bio() holding a mutex_lock while reading the fw binary.After that, a deadlock issue occurred while audio driver shutdown waswaiting for mutex_unlock of blk_mq_submit_bio(). To solve this, setSDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes downafter a UFS shutdown will return an error.[ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown][ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49][ 31.907806]I[0: swapper/0: 0] Call trace:[ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40[ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac[ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24[ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec[ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280[ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c[ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280[ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158[ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4[ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0[ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0[ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4[ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4[ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter][ 31.908783]I[0: swapper/0: 0] Call trace:[ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338[ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc[ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8[ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178[ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c[ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50099 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: probes: Remove broken LDR (literal) uprobe supportThe simulate_ldr_literal() and simulate_ldrsw_literal() functions areunsafe to use for uprobes. Both functions were originally written foruse with kprobes, and access memory with plain C accesses. When uprobeswas added, these were reused unmodified even though they cannot safelyaccess user memory.There are three key problems:1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()).2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN.3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers.Practically speaking, (1) and (2) are the big issues. Given there havebeen no reports of problems since the broken code was introduced, itappears that no-one is relying on probing these instructions withuprobes.Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW(literal), limiting the use of simulate_ldr_literal() andsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR(literal) and LDRSW (literal) will be rejected asarm_probe_decode_insn() will return INSN_REJECTED. In future we canconsider introducing working uprobes support for these instructions, butthis will require more significant work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()A devm_kzalloc() in asoc_qcom_lpass_cpu_platform_probe() couldpossibly return NULL pointer. NULL Pointer Dereference may betriggerred without addtional check.Add a NULL check for the returned pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix race between laundromat and free_stateidThere is a race between laundromat handling of revoked delegationsand a client sending free_stateid operation. Laundromat threadfinds that delegation has expired and needs to be revoked so itmarks the delegation stid revoked and it puts it on a reaper listbut then it unlock the state lock and the actual delegation revocationhappens without the lock. Once the stid is marked revoked a racingfree_stateid processing thread does the following (1) it callslist_del_init() which removes it from the reaper list and (2) freesthe delegation stid structure. The laundromat thread ends up notcalling the revoke_delegation() function for this particular delegationbut that means it will no release the lock lease that exists onthe file.Now, a new open for this file comes in and ends up finding thatlease list isn't empty and calls nfsd_breaker_owns_lease() which endsup trying to derefence a freed delegation stateid. Leading to thefollowint use-after-free KASAN warning:kernel: ==================================================================kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205kernel:kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024kernel: Call trace:kernel: dump_backtrace+0x98/0x120kernel: show_stack+0x1c/0x30kernel: dump_stack_lvl+0x80/0xe8kernel: print_address_description.constprop.0+0x84/0x390kernel: print_report+0xa4/0x268kernel: kasan_report+0xb4/0xf8kernel: __asan_report_load8_noabort+0x1c/0x28kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd]kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd]kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd]kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd]kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd]kernel: nfsd4_open+0xa08/0xe80 [nfsd]kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd]kernel: nfsd_dispatch+0x22c/0x718 [nfsd]kernel: svc_process_common+0x8e8/0x1960 [sunrpc]kernel: svc_process+0x3d4/0x7e0 [sunrpc]kernel: svc_handle_xprt+0x828/0xe10 [sunrpc]kernel: svc_recv+0x2cc/0x6a8 [sunrpc]kernel: nfsd+0x270/0x400 [nfsd]kernel: kthread+0x288/0x310kernel: ret_from_fork+0x10/0x20This patch proposes a fixed that's based on adding 2 new additionalstid's sc_status values that help coordinate between the laundromatand other operations (nfsd4_free_stateid() and nfsd4_delegreturn()).First to make sure, that once the stid is marked revoked, it is notremoved by the nfsd4_free_stateid(), the laundromat take a referenceon the stateid. Then, coordinating whether the stid has been puton the cl_revoked list or we are processing FREE_STATEID and need tomake sure to remove it from the list, each check that state and actaccordingly. If laundromat has added to the cl_revoke list beforethe arrival of FREE_STATEID, then nfsd4_free_stateid() knows to removeit from the list. If nfsd4_free_stateid() finds that operations arrivedbefore laundromat has placed it on cl_revoke list, it marks the statefreed and then laundromat will no longer add it to the list.Also, for nfsd4_delegreturn() when looking for the specified stid,we need to access stid that are marked removed or freeable, it meansthe laundromat has started processing it but hasn't finished and thisdelegreturn needs to return nfserr_deleg_revoked and notnfserr_bad_stateid. The latter will not trigger a FREE_STATEID and thelack of it will leave this stid on the cl_revoked list indefinitely.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50110 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: fix one more kernel-infoleak in algo dumpingDuring fuzz testing, the following issue was discovered:BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30 _copy_to_iter+0x598/0x2a30 __skb_datagram_iter+0x168/0x1060 skb_copy_datagram_iter+0x5b/0x220 netlink_recvmsg+0x362/0x1700 sock_recvmsg+0x2dc/0x390 __sys_recvfrom+0x381/0x6d0 __x64_sys_recvfrom+0x130/0x200 x64_sys_call+0x32c8/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was stored to memory at: copy_to_user_state_extra+0xcc1/0x1e00 dump_one_state+0x28c/0x5f0 xfrm_state_walk+0x548/0x11e0 xfrm_dump_sa+0x1e0/0x840 netlink_dump+0x943/0x1c40 __netlink_dump_start+0x746/0xdb0 xfrm_user_rcv_msg+0x429/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Uninit was created at: __kmalloc+0x571/0xd30 attach_auth+0x106/0x3e0 xfrm_add_sa+0x2aa0/0x4230 xfrm_user_rcv_msg+0x832/0xc00 netlink_rcv_skb+0x613/0x780 xfrm_netlink_rcv+0x77/0xc0 netlink_unicast+0xe90/0x1280 netlink_sendmsg+0x126d/0x1490 __sock_sendmsg+0x332/0x3d0 ____sys_sendmsg+0x863/0xc30 ___sys_sendmsg+0x285/0x3e0 __x64_sys_sendmsg+0x2d6/0x560 x64_sys_call+0x1316/0x3cc0 do_syscall_64+0xd8/0x1c0 entry_SYSCALL_64_after_hwframe+0x79/0x81Bytes 328-379 of 732 are uninitializedMemory access of size 732 starts at ffff88800e18e000Data copied to user address 00007ff30f48aff0CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Fixes copying of xfrm algorithms where some randomdata of the structure fields can end up in userspace.Padding in structures may be filled with random (possibly sensitve)data and should never be given directly to user-space.A similar issue was resolved in the commit8222d5910dae ("xfrm: Zero padding when dumping algos and encap")Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Consider the NULL character when validating the event lengthstrlen() returns a string length excluding the null byte. If the stringlength equals to the maximum buffer length, the buffer will have nospace for the NULL terminating character.This commit checks this condition and returns failure for it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50151 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix OOBs when building SMB2_IOCTL requestWhen using encryption, either enforced by the server or when using'seal' mount option, the client will squash all compound request buffersdown for encryption into a single iov in smb2_set_next_command().SMB2_ioctl_init() allocates a small buffer (448 bytes) to hold theSMB2_IOCTL request in the first iov, and if the user passes an inputbuffer that is greater than 328 bytes, smb2_set_next_command() willend up writing off the end of @rqst->iov[0].iov_base as shown below: mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link BUG: KASAN: slab-out-of-bounds in smb2_set_next_command.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859 CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: dump_stack_lvl+0x5d/0x80 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] print_report+0x156/0x4d9 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] ? __virt_addr_valid+0x145/0x310 ? __phys_addr+0x46/0x90 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_report+0xda/0x110 ? smb2_set_next_command.cold+0x1d6/0x24c [cifs] kasan_check_range+0x10f/0x1f0 __asan_memcpy+0x3c/0x60 smb2_set_next_command.cold+0x1d6/0x24c [cifs] smb2_compound_op+0x238c/0x3840 [cifs] ? kasan_save_track+0x14/0x30 ? kasan_save_free_info+0x3b/0x70 ? vfs_symlink+0x1a1/0x2c0 ? do_symlinkat+0x108/0x1c0 ? __pfx_smb2_compound_op+0x10/0x10 [cifs] ? kmem_cache_free+0x118/0x3e0 ? cifs_get_writable_path+0xeb/0x1a0 [cifs] smb2_get_reparse_inode+0x423/0x540 [cifs] ? __pfx_smb2_get_reparse_inode+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? __kmalloc_noprof+0x37c/0x480 ? smb2_create_reparse_symlink+0x257/0x490 [cifs] ? smb2_create_reparse_symlink+0x38f/0x490 [cifs] smb2_create_reparse_symlink+0x38f/0x490 [cifs] ? __pfx_smb2_create_reparse_symlink+0x10/0x10 [cifs] ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? __build_path_from_dentry_optional_prefix+0x19d/0x2e0 [cifs] cifs_symlink+0x24f/0x960 [cifs] ? __pfx_make_vfsuid+0x10/0x10 ? __pfx_cifs_symlink+0x10/0x10 [cifs] ? make_vfsgid+0x6b/0xc0 ? generic_permission+0x96/0x2d0 vfs_symlink+0x1a1/0x2c0 do_symlinkat+0x108/0x1c0 ? __pfx_do_symlinkat+0x10/0x10 ? strncpy_from_user+0xaa/0x160 __x64_sys_symlinkat+0xb9/0xf0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50166 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fsl/fman: Fix refcount handling of fman-related devicesIn mac_probe() there are multiple calls to of_find_device_by_node(),fman_bind() and fman_port_bind() which takes references to of_dev->dev.Not all references taken by these calls are released later on error pathin mac_probe() and in mac_remove() which lead to reference leaks.Add references release.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:be2net: fix potential memory leak in be_xmit()The be_xmit() returns NETDEV_TX_OK without freeing skbin case of be_xmit_enqueue() fails, add dev_kfree_skb_any() to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50179 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: remove the incorrect Fw reference check when dirtying pagesWhen doing the direct-io reads it will also try to mark pages dirty,but for the read path it won't hold the Fw caps and there is casewill it get the Fw reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50182 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:secretmem: disable memfd_secret() if arch cannot set direct mapReturn -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). Thisis the case for example on some arm64 configurations, where marking 4kPTEs in the direct map not present can only be done if the direct map isset up at 4k granularity in the first place (as ARM's break-before-makesemantics do not easily allow breaking apart large/gigantic pages).More precisely, on arm64 systems with !can_set_direct_map(),set_direct_map_invalid_noflush() is a no-op, however it returns success(0) instead of an error. This means that memfd_secret will seemingly"work" (e.g. syscall succeeds, you can mmap the fd and fault in pages),but it does not actually achieve its goal of removing its memory from thedirect map.Note that with this patch, memfd_secret() will start erroring on systemswhere can_set_direct_map() returns false (arm64 withCONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n andCONFIG_KFENCE=n), but that still seems better than the current silentfailure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', mostarm64 systems actually have a working memfd_secret() and aren't beaffected.From going through the iterations of the original memfd_secret patchseries, it seems that disabling the syscall in these scenarios was theintended behavior [1] (preferred over havingset_direct_map_invalid_noflush return an error as that would result inSIGBUSes at page-fault time), however the check for it got dropped betweenv16 [2] and v17 [3], when secretmem moved away from CMA allocations.[1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/[2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t[3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: handle consistently DSS corruptionBugged peer implementation can send corrupted DSS options, consistentlyhitting a few warning in the data path. Use DEBUG_NET assertions, toavoid the splat on some builds and handle consistently the error, dumpingrelated MIBs and performing fallback and/or reset according to thesubflow type.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50186 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: explicitly clear the sk pointer, when pf->create failsWe have recently noticed the exact same KASAN splat as in commit6cd4a78d962b ("net: do not leave a dangling sk pointer, when socketcreation fails"). The problem is that commit did not fully address theproblem, as some pf->create implementations do not use sk_common_releasein their error paths.For example, we can use the same reproducer as in the above commit, butchanging ping to arping. arping uses AF_PACKET socket and if packet_createfails, it will just sk_free the allocated sk object.While we could chase all the pf->create implementations and make sure theyNULL the freed sk object on error from the socket, we can't guaranteefuture protocols will not make the same mistake.So it is easier to just explicitly NULL the sk pointer upon return frompf->create in __sock_create. We do know that pf->create always releases theallocated sk object on error, so if the pointer is not NULL, it isdefinitely dangling.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50187 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vc4: Stop the active perfmon before being destroyedUpon closing the file descriptor, the active performance monitor is notstopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`,the active performance monitor's pointer (`vc4->active_perfmon`) is stillretained.If we open a new file descriptor and submit a few jobs with performancemonitors, the driver will attempt to stop the active performance monitorusing the stale pointer in `vc4->active_perfmon`. However, this pointeris no longer valid because the previous process has already terminated,and all performance monitors associated with it have been destroyed andfreed.To fix this, when the active performance monitor belongs to a givenprocess, explicitly stop it before destroying and freeing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v4: Don't allow a VMOVP on a dying VPEKunkun Jiang reported that there is a small window of opportunity foruserspace to force a change of affinity for a VPE while the VPE has alreadybeen unmapped, but the corresponding doorbell interrupt still visible in/proc/irq/.Plug the race by checking the value of vmapp_count, which tracks whetherthe VPE is mapped ot not, and returning an error in this case.This involves making vmapp_count common to both GICv4.1 and its v4.0ancestor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:posix-clock: Fix missing timespec64 check in pc_clock_settime()As Andrew pointed out, it will make sense that the PTP corechecked timespec64 struct's tv_sec and tv_nsec range before callingptp->info->settime64().As the man manual of clock_settime() said, if tp.tv_sec is negative ortp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL,which include dynamic clocks which handles PTP clock, and the condition isconsistent with timespec64_valid(). As Thomas suggested, timespec64_valid()only check the timespec is valid, but not ensure that the time isin a valid range, so check it ahead using timespec64_valid_strict()in pc_clock_settime() and return -EINVAL if not valid.There are some drivers that use tp->tv_sec and tp->tv_nsec directly towrite registers without validity checks and assume that the higher layerhas checked it, which is dangerous and will benefit from this, such ashclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(),and some drivers can remove the checks of itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50196 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: ocelot: fix system hang on level based interruptsThe current implementation only calls chained_irq_enter() andchained_irq_exit() if it detects pending interrupts.```for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc);```However, in case of GPIO pin configured in level mode and the parentcontroller configured in edge mode, GPIO interrupt might be lowered by thehardware. In the result, if the interrupt is short enough, the parentinterrupt is still pending while the GPIO interrupt is cleared;chained_irq_enter() never gets called and the system hangs trying toservice the parent interrupt.Moving chained_irq_enter() and chained_irq_exit() outside the for loopensures that they are called even when GPIO interrupt is lowered by thehardware.The similar code with chained_irq_enter() / chained_irq_exit() functionswrapping interrupt checking loop may be found in many other drivers:```grep -r -A 10 chained_irq_enter drivers/pinctrl```

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Fix encoder->possible_clonesInclude the encoder itself in its possible_clones bitmask.In the past nothing validated that drivers were populatingpossible_clones correctly, but that changed in commit74d2aacbe840 ("drm: Validate encoder->possible_clones").Looks like radeon never got the memo and is still notfollowing the rules 100% correctly.This results in some warnings during driver initialization:Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7)WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c...(cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50202 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: propagate directory read errors from nilfs_find_entry()Syzbot reported that a task hang occurs in vcs_open() during a fuzzingtest for nilfs2.The root cause of this problem is that in nilfs_find_entry(), whichsearches for directory entries, ignores errors when loading a directorypage/folio via nilfs_get_folio() fails.If the filesystem images is corrupted, and the i_size of the directoryinode is large, and the directory page/folio is successfully read butfails the sanity check, for example when it is zero-filled,nilfs_check_folio() may continue to spit out error messages in bursts.Fix this issue by propagating the error to the callers when loading apage/folio fails in nilfs_find_entry().The current interface of nilfs_find_entry() and its callers is outdatedand cannot propagate error codes such as -EIO and -ENOMEM returned vianilfs_find_entry(), so fix it together.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: pass u64 to ocfs2_truncate_inline maybe overflowSyzbot reported a kernel BUG in ocfs2_truncate_inline. There are tworeasons for this: first, the parameter value passed is greater thanocfs2_max_inline_data_with_xattr, second, the start and end parameters ofocfs2_truncate_inline are "unsigned int".So, we need to add a sanity check for byte_start and byte_len right beforeocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greaterthan ocfs2_max_inline_data_with_xattr return -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: do not pass a stopped vif to the driver in .get_txpowerAvoid potentially crashing in the driver because of uninitialized private data

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_payload: sanitize offset and length before calling skb_checksum()If access to offset + length is larger than the skbuff length, thenskb_checksum() triggers BUG_ON().skb_checksum() internally subtracts the length parameter while iteratingover skbuff, BUG_ON(len) at the end of it checks that the expectedlength to be included in the checksum calculation is fully consumed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()I got a syzbot report without a repro [1] crashing in nf_send_reset6()I think the issue is that dev->hard_header_len is zero, and we attemptlater to push an Ethernet header.Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c.[1]skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc900045269b0 EFLAGS: 00010282RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4cccR10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003cFS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fdbeeb7d1ffCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ffRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8RBP: 00007fdbeebf12be R08: 0000000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix crash when config small gso_max_size/gso_ipv4_max_sizeConfig a small gso_max_size/gso_ipv4_max_size will lead to an underflowin sk_dst_gso_max_size(), which may trigger a BUG_ON crash,because sk->sk_gso_max_size would be much bigger than device limits.Call Trace:tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs)Add check for the minimum value of gso_max_size and gso_ipv4_max_size.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50271 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:signal: restore the override_rlimit logicPrior to commit d64696905554 ("Reimplement RLIMIT_SIGPENDING on top ofucounts") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class ofsignals. However now it's enforced unconditionally, even ifoverride_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGVsignal, sigqueue_alloc fails to allocate the necessary resources for thesignal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address andhandling the error. From the user-space perspective, applications areunaware that the limit has been reached and that the siginfo iseffectively 'corrupted'. This can lead to unpredictable behavior andcrashes, as we observed with java applications.Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skipthe comparison to max there if override_rlimit is set. This effectivelyrestores the old behavior.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: Fix bounds checking in filemap_read()If the caller supplies an iocb->ki_pos value that is close to thefilesystem upper limit, and an iterator with a count that causes us tooverflow that limit, then filemap_read() enters an infinite loop.This behaviour was discovered when testing xfstests generic/525 with the"localio" optimisation for loopback NFS mounts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: reinitialize delayed ref list after deleting it from the listAt insert_delayed_ref() if we need to update the action of an existingref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head'sref_add_list using list_del(), which leaves the ref's add_list membernot reinitialized, as list_del() sets the next and prev members of thelist to LIST_POISON1 and LIST_POISON2, respectively.If later we end up calling drop_delayed_ref() against the ref, which canhappen during merging or when destroying delayed refs due to a transactionabort, we can trigger a crash since at drop_delayed_ref() we calllist_empty() against the ref's add_list, which returns false sincethe list was not reinitialized after the list_del() and as a consequencewe call list_del() again at drop_delayed_ref(). This results in aninvalid list access since the next and prev members are set to poisonpointers, resulting in a splat if CONFIG_LIST_HARDENED andCONFIG_DEBUG_LIST are set or invalid poison pointer dereferencesotherwise.So fix this by deleting from the list with list_del_init() instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-tpg: prevent the risk of a division by zeroAs reported by Coverity, the logic at tpg_precalculate_line()blindly rescales the buffer even when scaled_witdh is equal tozero. If this ever happens, this will cause a division by zero.Instead, add a WARN_ON_ONCE() to trigger such cases and returnwithout doing any precalculation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: av7110: fix a spectre vulnerabilityAs warned by smatch: drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)There is a spectre-related vulnerability at the code. Fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50298 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: allocate vf_state during PF probesIn the previous implementation, vf_state is allocated memory only when VFis enabled. However, net_device_ops::ndo_set_vf_mac() may be called beforeVF is enabled to configure the MAC address of VF. If this is the case,enetc_pf_set_vf_mac() will access vf_state, resulting in access to a nullpointer. The simplified error log is as follows.root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89[ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004[ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy[ 173.641973] lr : do_setlink+0x4a8/0xec8[ 173.732292] Call trace:[ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80[ 173.738847] __rtnl_newlink+0x530/0x89c[ 173.742692] rtnl_newlink+0x50/0x7c[ 173.746189] rtnetlink_rcv_msg+0x128/0x390[ 173.750298] netlink_rcv_skb+0x60/0x130[ 173.754145] rtnetlink_rcv+0x18/0x24[ 173.757731] netlink_unicast+0x318/0x380[ 173.761665] netlink_sendmsg+0x17c/0x3c8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()The per-netns IP tunnel hash table is protected by the RTNL mutex andip_tunnel_find() is only called from the control path where the mutex istaken.Add a lockdep expression to hlist_for_each_entry_rcu() inip_tunnel_find() in order to validate that the mutex is held and tosilence the suspicious RCU usage warning [1].[1]WARNING: suspicious RCU usage6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted-----------------------------net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60stack backtrace:CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix potential invalid memory access in igb_init_module()The pci_register_driver() can fail and when this happened, the dca_notifierneeds to be unregistered, otherwise the dca_notifier can be called whenigb fails to install, resulting to invalid memory access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52559 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/gem: prevent integer overflow in msm_ioctl_gem_submit()The "submit->cmd[i].size" and "submit->cmd[i].offset" variables are u32values that come from the user via the submit_lookup_cmds() function.This addition could lead to an integer wrapping bug so use size_add()to prevent that.Patchwork: https://patchwork.freedesktop.org/patch/624696/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53050 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in hdcp2_get_capabilityAdd encoder check in intel_hdcp2_get_capability to avoidnull pointer error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/hdcp: Add encoder check in intel_hdcp_get_capabilitySometimes during hotplug scenario or suspend/resume scenario encoder isnot always initialized when intel_hdcp_get_capability adda check to avoid kernel null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: fix 6 GHz scan constructionIf more than 255 colocated APs exist for the set of allAPs found during 2.4/5 GHz scanning, then the 6 GHz scanconstruction will loop forever since the loop variablehas type u8, which can never reach the number found whenthat's bigger than 255, and is stored in a u32 variable.Also move it into the loops to have a smaller scope.Using a u32 there is fine, we limit the number of APs inthe scan list and each has a limit on the number of RNRentries due to the frame size. With a limit of 1000 scanresults, a frame size upper bound of 4096 (really it'smore like ~2300) and a TBTT entry size of at least 11,we get an upper bound for the number of ~372k, well inthe bounds of a u32.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB dataIn case the non-paged data of a SKB carries protocol header and protocolpayload to be transmitted on a certain platform that the DMA AXI addresswidth is configured to 40-bit/48-bit, or the size of the non-paged datais bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXIaddress width is configured to 32-bit, then this SKB requires at leasttwo DMA transmit descriptors to serve it.For example, three descriptors are allocated to split one DMA buffermapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2].Then three elements of tx_q->tx_skbuff_dma[] will be allocated to holdextra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2].Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA bufferaddress returned by DMA mapping call. stmmac_tx_clean() will try tounmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].bufis a valid buffer address.The expected behavior that saves DMA buffer address of this non-pageddata to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single();Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL;On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by theDMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer addressobviously, then the DMA buffer will be unmapped immediately.There may be a rare case that the DMA engine does not finish thepending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will gohorribly wrong, DMA is going to access a unmapped/unreferenced memoryregion, corrupted data will be transmited or iommu fault will betriggered :(In contrast, the for-loop that maps SKB fragments behaves perfectlyas expected, and that is how the driver should do for both non-pageddata and paged frags actually.This patch corrects DMA map/unmap sequences by fixing the array indexfor tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address.Tested and verified on DWXGMAC CORE 3.20a

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: Fix KMSAN warning in decode_getfattr_attrs()Fix the following KMSAN warning:CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G BTainted: [B]=BAD_PAGEHardware name: QEMU Standard PC (Q35 + ICH9, 2009)==========================================================================================================BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe KMSAN warning is triggered in decode_getfattr_attrs(), when callingdecode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is notinitialized.Fix the issue by initializing fattr->mdsthreshold to NULL innfs_fattr_init().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix lock recursionafs_wake_up_async_call() can incur lock recursion. The problem is that itis called from AF_RXRPC whilst holding the ->notify_lock, but it tries totake a ref on the afs_call struct in order to pass it to a work queue - butif the afs_call is already queued, we then have an extraneous ref that mustbe put... calling afs_put_call() may call back down into AF_RXRPC throughrxrpc_kernel_shutdown_call(), however, which might try taking the->notify_lock again.This case isn't very common, however, so defer it to a workqueue. The oopslooks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: defer partition scanningWe need to suppress the partition scan from occuring within thecontroller's scan_work context. If a path error occurs here, the IO willwait until a path becomes available or all paths are torn down, but thataction also occurs within scan_work, so it would deadlock. Defer thepartion scan to a different context that does not block scan_work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53103 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointerWhen hvs is released, there is a possibility that vsk->trans may notbe initialized to NULL, which could lead to a dangling pointer.This issue is resolved by initializing vsk->trans to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53112 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: uncache inode which has failed entering the groupSyzbot has reported the following BUG:kernel BUG at fs/ocfs2/uptodate.c:509!...Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particularinode in 'ocfs2_verify_group_and_input()', corresponding buffer headremains cached and subsequent call to the same 'ioctl()' for the sameinode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (tryingto cache the same buffer head of that inode). Fix this by uncachingthe buffer head with 'ocfs2_remove_from_cache()' on error path in'ocfs2_group_add()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53113 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix NULL pointer dereference in alloc_pages_bulk_noprofWe triggered a NULL pointer dereference for ac.preferred_zoneref->zone inalloc_pages_bulk_noprof() when the task is migrated between cpusets.When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be¤t->mems_allowed. when first_zones_zonelist() is called to findpreferred_zoneref, the ac->nodemask may be modified concurrently if thetask is migrated between different cpusets. Assuming we have 2 NUMA Node,when traversing Node1 in ac->zonelist, the nodemask is 2, and whentraversing Node2 in ac->zonelist, the nodemask is 1. As a result, theac->preferred_zoneref points to NULL zone.In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds aallowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leadingto NULL pointer dereference.__alloc_pages_noprof() fixes this issue by checking NULL pointer in commitea57485af8f4 ("mm, page_alloc: fix check for NULL preferred_zone") andcommit df76cee6bbeb ("mm, page_alloc: remove redundant checks from allocfastpath").To fix it, check NULL pointer for preferred_zoneref->zone.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio/vsock: Fix accept_queue memory leakAs the final stages of socket destruction may be delayed, it is possiblethat virtio_transport_recv_listen() will be called after the accept_queuehas been flushed, but before the SOCK_DONE flag has been set. As a result,sockets enqueued after the flush would remain unremoved, leading to amemory leak.vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK(!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) releaseclose_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound releaseIntroduce a sk_shutdown check to disallow vsock_enqueue_accept() duringsocket destruction.unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53120 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: CT: Fix null-ptr-deref in add rule err flowIn error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add()callback returns error, zone_rule->attr is used uninitiated. Fix it touse attr which has the needed pointer value.Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core]... Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fs, lock FTE when checking if activeThe referenced commits introduced a two-step process for deleting FTEs:- Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.- Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.However, this approach encounters a race condition if a rule with the samematch value is added simultaneously. In this scenario, fs_core may set thehardware deletion function to NULL prematurely, causing a panic duringsubsequent rule deletions.To prevent this, ensure the active flag of the FTE is checked under a lock,which will prevent the fs_core layer from attaching a new steering rule toan FTE that is in the process of deletion.[ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func[ 438.968205] ------------[ cut here ]------------[ 438.968654] refcount_t: decrement hit 0; leaking memory.[ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110[ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower][ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8[ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110[ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90[ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286[ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000[ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0[ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0[ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0[ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0[ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000[ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0[ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 438.986507] Call Trace:[ 438.986799] [ 438.987070] ? __warn+0x7d/0x110[ 438.987426] ? refcount_warn_saturate+0xfb/0x110[ 438.987877] ? report_bug+0x17d/0x190[ 438.988261] ? prb_read_valid+0x17/0x20[ 438.988659] ? handle_bug+0x53/0x90[ 438.989054] ? exc_invalid_op+0x14/0x70[ 438.989458] ? asm_exc_invalid_op+0x16/0x20[ 438.989883] ? refcount_warn_saturate+0xfb/0x110[ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core][ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core][ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core][ 438.992054] ? xas_load+0x9/0xb0[ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core][ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core][ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core][ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core][ 438.994728] tc_setup_cb_destroy+0xb9/0x190[ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower][ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower][ 438.996105] tc_new_tfilter+0x347/0xbc0[ 438.996503] ? __---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: cope racing subflow creation in mptcp_rcv_space_adjustAdditional active subflows - i.e. created by the in kernel pathmanager - are included into the subflow list before starting the3whs.A racing recvmsg() spooling data received on an already establishedsubflow would unconditionally call tcp_cleanup_rbuf() on all thecurrent subflows, potentially hitting a divide by zero error onthe newly created ones.Explicitly check that the subflow is in a suitable state beforeinvoking tcp_cleanup_rbuf().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix data-races around sk->sk_forward_allocSyzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]---Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add()concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked,which triggers a data-race around sk->sk_forward_alloc:tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add()In this syzkaller testcase, two threads calltcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes likethis: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() whensk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock().Fix the same issue in dccp_v6_do_rcv().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53129 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/rockchip: vop: Fix a dereferenced before check warningThe 'state' can't be NULL, we should check crtc_state.Fix warning:drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096vop_plane_atomic_async_check() warn: variable dereferenced before check'state' (see line 1077)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53130 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_dirty_buffer tracepointWhen using the "block:block_dirty_buffer" tracepoint, mark_buffer_dirty()may cause a NULL pointer dereference, or a general protection fault whenKASAN is enabled.This happens because, since the tracepoint was added inmark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_devregardless of whether the buffer head has a pointer to a block_devicestructure.In the current implementation, nilfs_grab_buffer(), which grabs a bufferto read (or create) a block of metadata, including b-tree node blocks,does not set the block device, but instead does so only if the buffer isnot in the "uptodate" state for each of its caller block readingfunctions. However, if the uptodate flag is set on a folio/page, and thebuffer heads are detached from it by try_to_free_buffers(), and new bufferheads are then attached by create_empty_buffers(), the uptodate flag maybe restored to each buffer without the block device being set tobh->b_bdev, and mark_buffer_dirty() may be called later in that state,resulting in the bug mentioned above.Fix this issue by making nilfs_grab_buffer() always set the block deviceof the super block structure to the buffer head, regardless of the stateof the buffer's uptodate flag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix null-ptr-deref in block_touch_buffer tracepointPatch series "nilfs2: fix null-ptr-deref bugs on block tracepoints".This series fixes null pointer dereference bugs that occur when usingnilfs2 and two block-related tracepoints.This patch (of 2):It has been reported that when using "block:block_touch_buffer"tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes aNULL pointer dereference, or a general protection fault when KASAN isenabled.This happens because since the tracepoint was added in touch_buffer(), itreferences the dev_t member bh->b_bdev->bd_dev regardless of whether thebuffer head has a pointer to a block_device structure. In the currentimplementation, the block_device structure is set after the functionreturns to the caller.Here, touch_buffer() is used to mark the folio/page that owns the bufferhead as accessed, but the common search helper for folio/page used by thecaller function was optimized to mark the folio/page as accessed when itwas reimplemented a long time ago, eliminating the need to calltouch_buffer() here in the first place.So this solves the issue by eliminating the touch_buffer() call itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53140 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: terminate outstanding dump on socket closeNetlink supports iterative dumping of data. It provides the familiesthe following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanupThe whole process is asynchronous and the repeated calls to .dumpdon't actually happen in a tight loop, but rather are triggeredin response to recvmsg() on the socket.This gives the user full control over the dump, but also means thatthe user can close the socket without getting to the end of the dump.To make sure .start is always paired with .done we check if thereis an ongoing dump before freeing the socket, and if so call .done.The complication is that sockets can get freed from BH and .doneis allowed to sleep. So we use a workqueue to defer the call, whenneeded.Unfortunately this does not work correctly. What we defer is notthe cleanup but rather releasing a reference on the socket.We have no guarantee that we own the last reference, if someoneelse holds the socket they may release it in BH and we're backto square one.The whole dance, however, appears to be unnecessary. Only the usercan interact with dumps, so we can clean up when socket is closed.And close always happens in process context. Some async code maystill access the socket after close, queue notification skbs to it etc.but no dumps can start, end or otherwise make progress.Delete the workqueue and flush the dump state directly from the releasehandler. Note that further cleanup is possible in -next, for instancewe now always call .done before releasing the main module reference,so dump doesn't have to take a reference of its own.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scpi: Check the DVFS OPP count returned by the firmwareFix a kernel crash with the below call trace when the SCPI firmwarereturns OPP count of zero.dvfs_info.opp_count may be zero on some platforms during the reboottest, and the kernel will crash after dereferencing the pointer tokcalloc(info->count, sizeof(*opp), GFP_KERNEL). | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028 | Mem abort info: | ESR = 0x96000004 | Exception class = DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | Data abort info: | ISV = 0, ISS = 0x00000004 | CM = 0, WnR = 0 | user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000faefa08c | [0000000000000028] pgd=0000000000000000 | Internal error: Oops: 96000004 [#1] SMP | scpi-hwmon: probe of PHYT000D:00 failed with error -110 | Process systemd-udevd (pid: 1701, stack limit = 0x00000000aaede86c) | CPU: 2 PID: 1701 Comm: systemd-udevd Not tainted 4.19.90+ #1 | Hardware name: PHYTIUM LTD Phytium FT2000/4/Phytium FT2000/4, BIOS | pstate: 60000005 (nZCv daif -PAN -UAO) | pc : scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | lr : clk_register+0x438/0x720 | Call trace: | scpi_dvfs_recalc_rate+0x40/0x58 [clk_scpi] | devm_clk_hw_register+0x50/0xa0 | scpi_clk_ops_init.isra.2+0xa0/0x138 [clk_scpi] | scpi_clocks_probe+0x528/0x70c [clk_scpi] | platform_drv_probe+0x58/0xa8 | really_probe+0x260/0x3d0 | driver_probe_device+0x12c/0x148 | device_driver_attach+0x74/0x98 | __driver_attach+0xb4/0xe8 | bus_for_each_dev+0x88/0xe0 | driver_attach+0x30/0x40 | bus_add_driver+0x178/0x2b0 | driver_register+0x64/0x118 | __platform_driver_register+0x54/0x60 | scpi_clocks_driver_init+0x24/0x1000 [clk_scpi] | do_one_initcall+0x54/0x220 | do_init_module+0x54/0x1c8 | load_module+0x14a4/0x1668 | __se_sys_finit_module+0xf8/0x110 | __arm64_sys_finit_module+0x24/0x30 | el0_svc_common+0x78/0x170 | el0_svc_handler+0x38/0x78 | el0_svc+0x8/0x340 | Code: 937d7c00 a94153f3 a8c27bfd f9400421 (b8606820) | ---[ end trace 06feb22469d89fa8 ]--- | Kernel panic - not syncing: Fatal exception | SMP: stopping secondary CPUs | Kernel Offset: disabled | CPU features: 0x10,a0002008 | Memory Limit: none

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: fastmap: Fix duplicate slab cache names while attachingSince commit 4c39529663b9 ("slab: Warn on duplicate cache names whenDEBUG_VM=y"), the duplicate slab cache names can be detected and akernel WARNING is thrown out.In UBI fast attaching process, alloc_ai() could be invoked twicewith the same slab cache name 'ubi_aeb_slab_cache', which will triggerfollowing warning messages: kmem_cache of name 'ubi_aeb_slab_cache' already exists WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107 __kmem_cache_create_args+0x100/0x5f0 Modules linked in: ubi(+) nandsim [last unloaded: nandsim] CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2 RIP: 0010:__kmem_cache_create_args+0x100/0x5f0 Call Trace: __kmem_cache_create_args+0x100/0x5f0 alloc_ai+0x295/0x3f0 [ubi] ubi_attach+0x3c3/0xcc0 [ubi] ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi] ubi_init+0x3fb/0x800 [ubi] do_init_module+0x265/0x7d0 __x64_sys_finit_module+0x7a/0xc0The problem could be easily reproduced by loading UBI device by fastmapwith CONFIG_DEBUG_VM=y.Fix it by using different slab names for alloc_ai() callers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: make sure cache entry active before cache_showThe function `c_show` was called with protection from RCU. This onlyensures that `cp` will not be freed. Therefore, the reference count for`cp` can drop to zero, which will trigger a refcount use-after-freewarning when `cache_get` is called. To resolve this issue, use`cache_get_rcu` to ensure that `cp` remains active.------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 7 PID: 822 at lib/refcount.c:25refcount_warn_saturate+0xb1/0x120CPU: 7 UID: 0 PID: 822 Comm: cat Not tainted 6.12.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb1/0x120Call Trace: c_show+0x2fc/0x380 [sunrpc] seq_read_iter+0x589/0x770 seq_read+0x1e5/0x270 proc_reg_read+0xe1/0x140 vfs_read+0x125/0x530 ksys_read+0xc1/0x160 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Add sanity NULL check for the default mmap fault handlerA driver might allow the mmap access before initializing itsruntime->dma_area properly. Add a proper NULL check before passing tovirt_to_page() for avoiding a panic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53183 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: net: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the uml_net instance. Otherwise, removing a network device willresult in a crash:RIP: 0033:net_device_release+0x10/0x6fRSP: 00000000e20c7c40 EFLAGS: 00010206RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6Kernel panic - not syncing: Segfault with no mmCPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1Workqueue: events mc_work_procStack: 627af028 62c7af00 e20c7c80 60276fcd 62778000 603f5820 627af028 00000000 e20c7cb0 603a2bcd 627af000 62770010Call Trace: [<60276fcd>] device_release+0x70/0xba [<603a2bcd>] kobject_put+0xba/0xe7 [<60277265>] put_device+0x19/0x1c [<60281266>] platform_device_put+0x26/0x29 [<60281e5f>] platform_device_unregister+0x2c/0x2e [<6002ec9c>] net_remove+0x63/0x69 [<60031316>] ? mconsole_reply+0x0/0x50 [<600310c8>] mconsole_remove+0x160/0x1cc [<60087d40>] ? __remove_hrtimer+0x38/0x74 [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 [<6006b3cf>] ? dl_server_stop+0x3f/0x48 [<6006b390>] ? dl_server_stop+0x0/0x48 [<600672e8>] ? dequeue_entities+0x327/0x390 [<60038fa6>] ? um_set_signals+0x0/0x43 [<6003070c>] mc_work_proc+0x77/0x91 [<60057664>] process_scheduled_works+0x1b3/0x2dd [<60055f32>] ? assign_work+0x0/0x58 [<60057f0a>] worker_thread+0x1e9/0x293 [<6005406f>] ? set_pf_worker+0x0/0x64 [<6005d65d>] ? arch_local_irq_save+0x0/0x2d [<6005d748>] ? kthread_exit+0x0/0x3a [<60057d21>] ? worker_thread+0x0/0x293 [<6005dbf1>] kthread+0x126/0x12b [<600219c5>] new_thread_handler+0x85/0xb6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:um: ubd: Do not use drvdata in releaseThe drvdata is not available in release. Let's just use container_of()to get the ubd instance. Otherwise, removing a ubd device will resultin a crash:RIP: 0033:blk_mq_free_tag_set+0x1f/0xbaRSP: 00000000e2083bf0 EFLAGS: 00010246RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0Kernel panic - not syncing: Segfault with no mmCPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1Workqueue: events mc_work_procStack: 00000000 604f7ef0 62c5d000 62405d20 e2083c30 6002c776 6002c755 600e47ff e2083c60 6025ffe3 04208060 603d36e0Call Trace: [<6002c776>] ubd_device_release+0x21/0x55 [<6002c755>] ? ubd_device_release+0x0/0x55 [<600e47ff>] ? kfree+0x0/0x100 [<6025ffe3>] device_release+0x70/0xba [<60381d6a>] kobject_put+0xb5/0xe2 [<6026027b>] put_device+0x19/0x1c [<6026a036>] platform_device_put+0x26/0x29 [<6026ac5a>] platform_device_unregister+0x2c/0x2e [<6002c52e>] ubd_remove+0xb8/0xd6 [<6002bb74>] ? mconsole_reply+0x0/0x50 [<6002b926>] mconsole_remove+0x160/0x1cc [<6002bbbc>] ? mconsole_reply+0x48/0x50 [<6003379c>] ? um_set_signals+0x3b/0x43 [<60061c55>] ? update_min_vruntime+0x14/0x70 [<6006251f>] ? dequeue_task_fair+0x164/0x235 [<600620aa>] ? update_cfs_group+0x0/0x40 [<603a0e77>] ? __schedule+0x0/0x3ed [<60033761>] ? um_set_signals+0x0/0x43 [<6002af6a>] mc_work_proc+0x77/0x91 [<600520b4>] process_scheduled_works+0x1af/0x2c3 [<6004ede3>] ? assign_work+0x0/0x58 [<600527a1>] worker_thread+0x2f7/0x37a [<6004ee3b>] ? set_pf_worker+0x0/0x64 [<6005765d>] ? arch_local_irq_save+0x0/0x2d [<60058e07>] ? kthread_exit+0x0/0x3a [<600524aa>] ? worker_thread+0x0/0x37a [<60058f9f>] kthread+0x130/0x135 [<6002068e>] new_thread_handler+0x85/0xb6

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix NULL ptr deref in crypto_aead_setkey()Neither SMB3.0 or SMB3.02 supports encryption negotiate context, sowhen SMB2_GLOBAL_CAP_ENCRYPTION flag is set in the negotiate response,the client uses AES-128-CCM as the default cipher. See MS-SMB23.3.5.4.Commit b0abcd65ec54 ("smb: client: fix UAF in async decryption") addeda @server->cipher_type check to conditionally callsmb3_crypto_aead_allocate(), but that check would always be false as@server->cipher_type is unset for SMB3.02.Fix the following KASAN splat by setting @server->cipher_type forSMB3.02 as well.mount.cifs //srv/share /mnt -o vers=3.02,seal,...BUG: KASAN: null-ptr-deref in crypto_aead_setkey+0x2c/0x130Read of size 8 at addr 0000000000000020 by task mount.cifs/1095CPU: 1 UID: 0 PID: 1095 Comm: mount.cifs Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 ? crypto_aead_setkey+0x2c/0x130 kasan_report+0xda/0x110 ? crypto_aead_setkey+0x2c/0x130 crypto_aead_setkey+0x2c/0x130 crypt_message+0x258/0xec0 [cifs] ? __asan_memset+0x23/0x50 ? __pfx_crypt_message+0x10/0x10 [cifs] ? mark_lock+0xb0/0x6a0 ? hlock_class+0x32/0xb0 ? mark_lock+0xb0/0x6a0 smb3_init_transform_rq+0x352/0x3f0 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 smb_send_rqst+0x144/0x230 [cifs] ? __pfx_smb_send_rqst+0x10/0x10 [cifs] ? hlock_class+0x32/0xb0 ? smb2_setup_request+0x225/0x3a0 [cifs] ? __pfx_cifs_compound_last_callback+0x10/0x10 [cifs] compound_send_recv+0x59b/0x1140 [cifs] ? __pfx_compound_send_recv+0x10/0x10 [cifs] ? __create_object+0x5e/0x90 ? hlock_class+0x32/0xb0 ? do_raw_spin_unlock+0x9a/0xf0 cifs_send_recv+0x23/0x30 [cifs] SMB2_tcon+0x3ec/0xb30 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? __pfx_lock_release+0x10/0x10 ? do_raw_spin_trylock+0xc6/0x120 ? lock_acquire+0x3f/0x90 ? _get_xid+0x16/0xd0 [cifs] ? __pfx_SMB2_tcon+0x10/0x10 [cifs] ? cifs_get_smb_ses+0xcdd/0x10a0 [cifs] cifs_get_smb_ses+0xcdd/0x10a0 [cifs] ? __pfx_cifs_get_smb_ses+0x10/0x10 [cifs] ? cifs_get_tcp_session+0xaa0/0xca0 [cifs] cifs_mount_get_session+0x8a/0x210 [cifs] dfs_mount_share+0x1b0/0x11d0 [cifs] ? __pfx___lock_acquire+0x10/0x10 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? lock_acquire.part.0+0xf4/0x2a0 ? find_held_lock+0x8a/0xa0 ? hlock_class+0x32/0xb0 ? lock_release+0x203/0x5d0 cifs_mount+0xb3/0x3d0 [cifs] ? do_raw_spin_trylock+0xc6/0x120 ? __pfx_cifs_mount+0x10/0x10 [cifs] ? lock_acquire+0x3f/0x90 ? find_nls+0x16/0xa0 ? smb3_update_mnt_flags+0x372/0x3b0 [cifs] cifs_smb3_do_mount+0x1e2/0xc80 [cifs] ? __pfx_vfs_parse_fs_string+0x10/0x10 ? __pfx_cifs_smb3_do_mount+0x10/0x10 [cifs] smb3_get_tree+0x1bf/0x330 [cifs] vfs_get_tree+0x4a/0x160 path_mount+0x3c1/0xfb0 ? kasan_quarantine_put+0xc7/0x1d0 ? __pfx_path_mount+0x10/0x10 ? kmem_cache_free+0x118/0x3e0 ? user_path_at+0x74/0xa0 __x64_sys_mount+0x1a6/0x1e0 ? __pfx___x64_sys_mount+0x10/0x10 ? mark_held_locks+0x1a/0x90 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53210 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()Passing MSG_PEEK flag to skb_recv_datagram() increments skb refcount(skb->users) and iucv_sock_recvmsg() does not decrement skb refcountat exit.This results in skb memory leak in skb_queue_purge() and WARN_ON iniucv_sock_destruct() during socket close. To fix this decreaseskb refcount by one if MSG_PEEK is set in order to prevent memoryleak and WARN_ON.WARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]CPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G W 6.10.0-rc7 #1Hardware name: IBM 3931 A01 704 (z/VM 7.3.0)Call Trace: [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv] [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv] [<001587c704117a32>] __sk_destruct+0x52/0x550 [<001587c704104a54>] __sock_release+0xa4/0x230 [<001587c704104c0c>] sock_close+0x2c/0x40 [<001587c702c5f5a8>] __fput+0x2e8/0x970 [<001587c7024148c4>] task_work_run+0x1c4/0x2c0 [<001587c7023b0716>] do_exit+0x996/0x1050 [<001587c7023b13aa>] do_group_exit+0x13a/0x360 [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60 [<001587c7022bccca>] do_syscall+0x27a/0x380 [<001587c7049a6a0c>] __do_syscall+0x9c/0x160 [<001587c7049ce8a8>] system_call+0x70/0x98 Last Breaking-Event-Address: [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53215 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()There's issue as follows:RPC: Registered rdma transport module.RPC: Registered rdma backchannel transport module.RPC: Unregistered rdma transport module.RPC: Unregistered rdma backchannel transport module.BUG: unable to handle page fault for address: fffffbfff80c609aPGD 123fee067 P4D 123fee067 PUD 123fea067 PMD 10c624067 PTE 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTIRIP: 0010:percpu_counter_destroy_many+0xf7/0x2a0Call Trace: __die+0x1f/0x70 page_fault_oops+0x2cd/0x860 spurious_kernel_fault+0x36/0x450 do_kern_addr_fault+0xca/0x100 exc_page_fault+0x128/0x150 asm_exc_page_fault+0x26/0x30 percpu_counter_destroy_many+0xf7/0x2a0 mmdrop+0x209/0x350 finish_task_switch.isra.0+0x481/0x840 schedule_tail+0xe/0xd0 ret_from_fork+0x23/0x80 ret_from_fork_asm+0x1a/0x30 If register_sysctl() return NULL, then svc_rdma_proc_cleanup() will notdestroy the percpu counters which init in svc_rdma_proc_init().If CONFIG_HOTPLUG_CPU is enabled, residual nodes may be in the'percpu_counters' list. The above issue may occur once the module isremoved. If the CONFIG_HOTPLUG_CPU configuration is not enabled, memoryleakage occurs.To solve above issue just destroy all percpu counters whenregister_sysctl() return NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Prevent NULL dereference in nfsd4_process_cb_update()@ses is initialized to NULL. If __nfsd4_find_backchannel() finds noavailable backchannel session, setup_callback_client() will try todereference @ses and segfault.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: use pages instead of pointer for kernel direct IOWhen trying to insert a 10MB kernel module kept in a virtio-fs with cachedisabled, the following warning was reported: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 404 at mm/page_alloc.c:4551 ...... Modules linked in: CPU: 1 PID: 404 Comm: insmod Not tainted 6.9.0-rc5+ #123 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ...... RIP: 0010:__alloc_pages+0x2bf/0x380 ...... Call Trace: ? __warn+0x8e/0x150 ? __alloc_pages+0x2bf/0x380 __kmalloc_large_node+0x86/0x160 __kmalloc+0x33c/0x480 virtio_fs_enqueue_req+0x240/0x6d0 virtio_fs_wake_pending_and_unlock+0x7f/0x190 queue_request_and_unlock+0x55/0x60 fuse_simple_request+0x152/0x2b0 fuse_direct_io+0x5d2/0x8c0 fuse_file_read_iter+0x121/0x160 __kernel_read+0x151/0x2d0 kernel_read+0x45/0x50 kernel_read_file+0x1a9/0x2a0 init_module_from_file+0x6a/0xe0 idempotent_init_module+0x175/0x230 __x64_sys_finit_module+0x5d/0xb0 x64_sys_call+0x1c3/0x9e0 do_syscall_64+0x3d/0xc0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 ...... ---[ end trace 0000000000000000 ]---The warning is triggered as follows:1) syscall finit_module() handles the module insertion and it invokeskernel_read_file() to read the content of the module first.2) kernel_read_file() allocates a 10MB buffer by using vmalloc() andpasses it to kernel_read(). kernel_read() constructs a kvec iter byusing iov_iter_kvec() and passes it to fuse_file_read_iter().3) virtio-fs disables the cache, so fuse_file_read_iter() invokesfuse_direct_io(). As for now, the maximal read size for kvec iter isonly limited by fc->max_read. For virtio-fs, max_read is UINT_MAX, sofuse_direct_io() doesn't split the 10MB buffer. It saves the address andthe size of the 10MB-sized buffer in out_args[0] of a fuse request andpasses the fuse request to virtio_fs_wake_pending_and_unlock().4) virtio_fs_wake_pending_and_unlock() uses virtio_fs_enqueue_req() toqueue the request. Because virtiofs need DMA-able address, sovirtio_fs_enqueue_req() uses kmalloc() to allocate a bounce buffer forall fuse args, copies these args into the bounce buffer and passed thephysical address of the bounce buffer to virtiofsd. The total length ofthese fuse args for the passed fuse request is about 10MB, socopy_args_to_argbuf() invokes kmalloc() with a 10MB size parameter andit triggers the warning in __alloc_pages(): if (WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)) return NULL;5) virtio_fs_enqueue_req() will retry the memory allocation in akworker, but it won't help, because kmalloc() will always return NULLdue to the abnormal size and finit_module() will hang forever.A feasible solution is to limit the value of max_read for virtio-fs, sothe length passed to kmalloc() will be limited. However it will affectthe maximal read size for normal read. And for virtio-fs write initiatedfrom kernel, it has the similar problem but now there is no way to limitfc->max_write in kernel.So instead of limiting both the values of max_read and max_write inkernel, introducing use_pages_for_kvec_io in fuse_conn and setting it astrue in virtiofs. When use_pages_for_kvec_io is enabled, fuse will usepages instead of pointer to pass the KVEC_IO data.After switching to pages for KVEC_IO data, these pages will be used forDMA through virtio-fs. If these pages are backed by vmalloc(),{flush|invalidate}_kernel_vmap_range() are necessary to flush orinvalidate the cache before the DMA operation. So add two new fields infuse_args_pages to record the base address of vmalloc area and thecondition indicating whether invalidation is needed. Perform the flushin fuse_get_user_pages() for write operations and the invalidation infuse_release_user_pages() for read operations.It may seem necessary to introduce another fie---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53220 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to account dirty data in __get_secs_required()It will trigger system panic w/ testcase in [1]:------------[ cut here ]------------kernel BUG at fs/f2fs/segment.c:2752!RIP: 0010:new_curseg+0xc81/0x2110Call Trace: f2fs_allocate_data_block+0x1c91/0x4540 do_write_page+0x163/0xdf0 f2fs_outplace_write_data+0x1aa/0x340 f2fs_do_write_data_page+0x797/0x2280 f2fs_write_single_data_page+0x16cd/0x2190 f2fs_write_cache_pages+0x994/0x1c80 f2fs_write_data_pages+0x9cc/0xea0 do_writepages+0x194/0x7a0 filemap_fdatawrite_wbc+0x12b/0x1a0 __filemap_fdatawrite_range+0xbb/0xf0 file_write_and_wait_range+0xa1/0x110 f2fs_do_sync_file+0x26f/0x1c50 f2fs_sync_file+0x12b/0x1d0 vfs_fsync_range+0xfa/0x230 do_fsync+0x3d/0x80 __x64_sys_fsync+0x37/0x50 x64_sys_call+0x1e88/0x20d0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe root cause is if checkpoint_disabling and lfs_mode are both on,it will trigger OPU for all overwritten data, it may cost more freesegment than expected, so f2fs must account those data correctly tocalculate cosumed free segments later, and return ENOSPC earlier toavoid run out of free segment during block allocation.[1] https://lore.kernel.org/fstests/20241015025106.3203676-1-chao@kernel.org/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Fix use-after-free in bfad_im_module_exit()BUG: KASAN: slab-use-after-free in __lock_acquire+0x2aca/0x3a20Read of size 8 at addr ffff8881082d80c8 by task modprobe/25303Call Trace: dump_stack_lvl+0x95/0xe0 print_report+0xcb/0x620 kasan_report+0xbd/0xf0 __lock_acquire+0x2aca/0x3a20 lock_acquire+0x19b/0x520 _raw_spin_lock+0x2b/0x40 attribute_container_unregister+0x30/0x160 fc_release_transport+0x19/0x90 [scsi_transport_fc] bfad_im_module_exit+0x23/0x60 [bfa] bfad_init+0xdb/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Allocated by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 fc_attach_transport+0x4f/0x4740 [scsi_transport_fc] bfad_im_module_init+0x17/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fFreed by task 25303: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x38/0x50 kfree+0x212/0x480 bfad_im_module_init+0x7e/0x80 [bfa] bfad_init+0x23/0xff0 [bfa] do_one_initcall+0xdc/0x550 do_init_module+0x22d/0x6b0 load_module+0x4e96/0x5ff0 init_module_from_file+0xcd/0x130 idempotent_init_module+0x330/0x620 __x64_sys_finit_module+0xb3/0x110 do_syscall_64+0xc1/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fAbove issue happens as follows:bfad_init error = bfad_im_module_init() fc_release_transport(bfad_im_scsi_transport_template); if (error) goto ext;ext: bfad_im_module_exit(); fc_release_transport(bfad_im_scsi_transport_template); --> Trigger double releaseDon't call bfad_im_module_exit() if bfad_im_module_init() failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-54458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: bsg: Set bsg_queue to NULL after removalCurrently, this does not cause any issues, but I believe it is necessary toset bsg_queue to NULL after removing it to prevent potential use-after-free(UAF) access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-55881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Play nice with protected guests in complete_hypercall_exit()Use is_64_bit_hypercall() instead of is_64_bit_mode() to detect a 64-bithypercall when completing said hypercall. For guests with protected state,e.g. SEV-ES and SEV-SNP, KVM must assume the hypercall was made in 64-bitmode as the vCPU state needed to detect 64-bit mode is unavailable.Hacking the sev_smoke_test selftest to generate a KVM_HC_MAP_GPA_RANGEhypercall via VMGEXIT trips the WARN: ------------[ cut here ]------------ WARNING: CPU: 273 PID: 326626 at arch/x86/kvm/x86.h:180 complete_hypercall_exit+0x44/0xe0 [kvm] Modules linked in: kvm_amd kvm ... [last unloaded: kvm] CPU: 273 UID: 0 PID: 326626 Comm: sev_smoke_test Not tainted 6.12.0-smp--392e932fa0f3-feat #470 Hardware name: Google Astoria/astoria, BIOS 0.20240617.0-0 06/17/2024 RIP: 0010:complete_hypercall_exit+0x44/0xe0 [kvm] Call Trace: kvm_arch_vcpu_ioctl_run+0x2400/0x2720 [kvm] kvm_vcpu_ioctl+0x54f/0x630 [kvm] __se_sys_ioctl+0x6b/0xc0 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/modes: Avoid divide by zero harder in drm_mode_vrefresh()drm_mode_vrefresh() is trying to avoid divide by zeroby checking whether htotal or vtotal are zero. But we maystill end up with a div-by-zero of vtotal*htotal*...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56538 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: zynqmp_kms: Unplug DRM device before removalPrevent userspace accesses to the DRM device from causinguse-after-frees by unplugging the device before we remove it. Thiscauses any further userspace accesses to result in an error withoutfurther calls into this driver's internals.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56562 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: master: Fix miss free init_dyn_addr at i3c_master_put_i3c_addrs()if (dev->boardinfo && dev->boardinfo->init_dyn_addr) ^^^ here check "init_dyn_addr" i3c_bus_set_addr_slot_status(&master->bus, dev->info.dyn_addr, ...) ^^^^ free "dyn_addr"Fix copy/paste error "dyn_addr" by replacing it with "init_dyn_addr".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56567 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ad7780: fix division by zero in ad7780_write_raw()In the ad7780_write_raw() , val2 can be zero, which might lead to adivision by zero error in DIV_ROUND_CLOSEST(). The ad7780_write_raw()is based on iio_info's write_raw. While val is explicitly declared thatcan be zero (in read mode), val2 is not specified to be non-zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56575 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Ensure power suppliers be suspended before detach themThe power suppliers are always requested to suspend asynchronously,dev_pm_domain_detach() requires the caller to ensure propersynchronization of this function with power management callbacks.otherwise the detach may led to kernel panic, like below:[ 1457.107934] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000040[ 1457.116777] Mem abort info:[ 1457.119589] ESR = 0x0000000096000004[ 1457.123358] EC = 0x25: DABT (current EL), IL = 32 bits[ 1457.128692] SET = 0, FnV = 0[ 1457.131764] EA = 0, S1PTW = 0[ 1457.134920] FSC = 0x04: level 0 translation fault[ 1457.139812] Data abort info:[ 1457.142707] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 1457.148196] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 1457.153256] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 1457.158563] user pgtable: 4k pages, 48-bit VAs, pgdp=00000001138b6000[ 1457.165000] [0000000000000040] pgd=0000000000000000, p4d=0000000000000000[ 1457.171792] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 1457.178045] Modules linked in: v4l2_jpeg wave6_vpu_ctrl(-) [last unloaded: mxc_jpeg_encdec][ 1457.186383] CPU: 0 PID: 51938 Comm: kworker/0:3 Not tainted 6.6.36-gd23d64eea511 #66[ 1457.194112] Hardware name: NXP i.MX95 19X19 board (DT)[ 1457.199236] Workqueue: pm pm_runtime_work[ 1457.203247] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 1457.210188] pc : genpd_runtime_suspend+0x20/0x290[ 1457.214886] lr : __rpm_callback+0x48/0x1d8[ 1457.218968] sp : ffff80008250bc50[ 1457.222270] x29: ffff80008250bc50 x28: 0000000000000000 x27: 0000000000000000[ 1457.229394] x26: 0000000000000000 x25: 0000000000000008 x24: 00000000000f4240[ 1457.236518] x23: 0000000000000000 x22: ffff00008590f0e4 x21: 0000000000000008[ 1457.243642] x20: ffff80008099c434 x19: ffff00008590f000 x18: ffffffffffffffff[ 1457.250766] x17: 5300326563697665 x16: 645f676e696c6f6f x15: 63343a6d726f6674[ 1457.257890] x14: 0000000000000004 x13: 00000000000003a4 x12: 0000000000000002[ 1457.265014] x11: 0000000000000000 x10: 0000000000000a60 x9 : ffff80008250bbb0[ 1457.272138] x8 : ffff000092937200 x7 : ffff0003fdf6af80 x6 : 0000000000000000[ 1457.279262] x5 : 00000000410fd050 x4 : 0000000000200000 x3 : 0000000000000000[ 1457.286386] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff00008590f000[ 1457.293510] Call trace:[ 1457.295946] genpd_runtime_suspend+0x20/0x290[ 1457.300296] __rpm_callback+0x48/0x1d8[ 1457.304038] rpm_callback+0x6c/0x78[ 1457.307515] rpm_suspend+0x10c/0x570[ 1457.311077] pm_runtime_work+0xc4/0xc8[ 1457.314813] process_one_work+0x138/0x248[ 1457.318816] worker_thread+0x320/0x438[ 1457.322552] kthread+0x110/0x114[ 1457.325767] ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56576 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: tc358743: Fix crash in the probe error path when using pollingIf an error occurs in the probe() function, we should remove the pollingtimer that was alarmed earlier, otherwise the timer is called witharguments that are already freed, which results in a crash.------------[ cut here ]------------WARNING: CPU: 3 PID: 0 at kernel/time/timer.c:1830 __run_timers+0x244/0x268Modules linked in:CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.11.0 #226Hardware name: Diasom DS-RK3568-SOM-EVB (DT)pstate: 804000c9 (Nzcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __run_timers+0x244/0x268lr : __run_timers+0x1d4/0x268sp : ffffff80eff2baf0x29: ffffff80eff2bb50 x28: 7fffffffffffffff x27: ffffff80eff2bb00x26: ffffffc080f669c0 x25: ffffff80efef6bf0 x24: ffffff80eff2bb00x23: 0000000000000000 x22: dead000000000122 x21: 0000000000000000x20: ffffff80efef6b80 x19: ffffff80041c8bf8 x18: ffffffffffffffffx17: ffffffc06f146000 x16: ffffff80eff27dc0 x15: 000000000000003ex14: 0000000000000000 x13: 00000000000054da x12: 0000000000000000x11: 00000000000639c0 x10: 000000000000000c x9 : 0000000000000009x8 : ffffff80eff2cb40 x7 : ffffff80eff2cb40 x6 : ffffff8002bee480x5 : ffffffc080cb2220 x4 : ffffffc080cb2150 x3 : 00000000000f4240x2 : 0000000000000102 x1 : ffffff80eff2bb00 x0 : ffffff80041c8bf0Call trace: __run_timers+0x244/0x268 timer_expire_remote+0x50/0x68 tmigr_handle_remote+0x388/0x39c run_timer_softirq+0x38/0x44 handle_softirqs+0x138/0x298 __do_softirq+0x14/0x20 ____do_softirq+0x10/0x1c call_on_irq_stack+0x24/0x4c do_softirq_own_stack+0x1c/0x2c irq_exit_rcu+0x9c/0xcc el1_interrupt+0x48/0xc0 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x7c/0x80 default_idle_call+0x34/0x68 do_idle+0x23c/0x294 cpu_startup_entry+0x38/0x3c secondary_start_kernel+0x128/0x160 __secondary_switched+0xb8/0xbc---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56578 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Set video drvdata before register video deviceThe video drvdata should be set before the video device is registered,otherwise video_drvdata() may return NULL in the open() file ops, and ledto oops.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: ref-verify: fix use-after-free after invalid ref actionAt btrfs_ref_tree_mod() after we successfully inserted the new ref entry(local variable 'ref') into the respective block entry's rbtree (localvariable 'be'), if we find an unexpected action of BTRFS_DROP_DELAYED_REF,we error out and free the ref entry without removing it from the blockentry's rbtree. Then in the error path of btrfs_ref_tree_mod() we callbtrfs_free_ref_cache(), which iterates over all block entries and thencalls free_block_entry() for each one, and there we will trigger ause-after-free when we are called against the block entry to which weadded the freed ref entry to its rbtree, since the rbtree still pointsto the block entry, as we didn't remove it from the rbtree before freeingit in the error path at btrfs_ref_tree_mod(). Fix this by removing thenew ref entry from the rbtree before freeing it.Syzbot report this with the following stack traces: BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_insert_empty_items+0x9c/0x1a0 fs/btrfs/ctree.c:4314 btrfs_insert_empty_item fs/btrfs/ctree.h:669 [inline] btrfs_insert_orphan_item+0x1f1/0x320 fs/btrfs/orphan.c:23 btrfs_orphan_add+0x6d/0x1a0 fs/btrfs/inode.c:3482 btrfs_unlink+0x267/0x350 fs/btrfs/inode.c:4293 vfs_unlink+0x365/0x650 fs/namei.c:4469 do_unlinkat+0x4ae/0x830 fs/namei.c:4533 __do_sys_unlinkat fs/namei.c:4576 [inline] __se_sys_unlinkat fs/namei.c:4569 [inline] __x64_sys_unlinkat+0xcc/0xf0 fs/namei.c:4569 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f BTRFS error (device loop0 state EA): Ref action 1, root 5, ref_root 5, parent 0, owner 260, offset 0, num_refs 1 __btrfs_mod_ref+0x76b/0xac0 fs/btrfs/extent-tree.c:2521 update_ref_for_cow+0x96a/0x11f0 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1114 [inline] __btrfs_commit_inode_delayed_items+0x2318/0x24a0 fs/btrfs/delayed-inode.c:1137 __btrfs_run_delayed_items+0x213/0x490 fs/btrfs/delayed-inode.c:1171 btrfs_commit_transaction+0x8a8/0x3740 fs/btrfs/transaction.c:2313 prepare_to_relocate+0x3c4/0x4c0 fs/btrfs/relocation.c:3586 relocate_block_group+0x16c/0xd40 fs/btrfs/relocation.c:3611 btrfs_relocate_block_group+0x77d/0xd90 fs/btrfs/relocation.c:4081 btrfs_relocate_chunk+0x12c/0x3b0 fs/btrfs/volumes.c:3377 __btrfs_balance+0x1b0f/0x26b0 fs/btrfs/volumes.c:4161 btrfs_balance+0xbdc/0x10c0 fs/btrfs/volumes.c:4538 BTRFS error (device loop0 state EA): Ref action 2, root 5, ref_root 0, parent 8564736, owner 0, offset 0, num_refs 18446744073709551615 __btrfs_mod_ref+0x7dd/0xac0 fs/btrfs/extent-tree.c:2523 update_ref_for_cow+0x9cd/0x11f0 fs/btrfs/ctree.c:512 btrfs_force_cow_block+0x9f6/0x1da0 fs/btrfs/ctree.c:594 btrfs_cow_block+0x35e/0xa40 fs/btrfs/ctree.c:754 btrfs_search_slot+0xbdd/0x30d0 fs/btrfs/ctree.c:2116 btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:411 __btrfs_update_delayed_inode+0x1e7/0xb90 fs/btrfs/delayed-inode.c:1030 btrfs_update_delayed_i---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56583 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix warning in migrate_enable for boosted tasksWhen running the following command:while true; do stress-ng --cyclic 30 --timeout 30s --minimize --quietdonea warning is eventually triggered:WARNING: CPU: 43 PID: 2848 at kernel/sched/deadline.c:794setup_new_dl_entity+0x13e/0x180...Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? enqueue_dl_entity+0x631/0x6e0 ? setup_new_dl_entity+0x13e/0x180 ? __warn+0x7e/0xd0 ? report_bug+0x11a/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 enqueue_dl_entity+0x631/0x6e0 enqueue_task_dl+0x7d/0x120 __do_set_cpus_allowed+0xe3/0x280 __set_cpus_allowed_ptr_locked+0x140/0x1d0 __set_cpus_allowed_ptr+0x54/0xa0 migrate_enable+0x7e/0x150 rt_spin_unlock+0x1c/0x90 group_send_sig_info+0xf7/0x1a0 ? kill_pid_info+0x1f/0x1d0 kill_pid_info+0x78/0x1d0 kill_proc_info+0x5b/0x110 __x64_sys_kill+0x93/0xc0 do_syscall_64+0x5c/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 RIP: 0033:0x7f0dab31f92bThis warning occurs because set_cpus_allowed dequeues and enqueues taskswith the ENQUEUE_RESTORE flag set. If the task is boosted, the warningis triggered. A boosted task already had its parameters set byrt_mutex_setprio, and a new call to setup_new_dl_entity is unnecessary,hence the WARN_ON call.Check if we are requeueing a boosted task and avoid callingsetup_new_dl_entity if that's the case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56584 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/tctx: work around xa_store() allocation error issuesyzbot triggered the following WARN_ON:WARNING: CPU: 0 PID: 16 at io_uring/tctx.c:51 __io_uring_free+0xfa/0x140 io_uring/tctx.c:51which is theWARN_ON_ONCE(!xa_empty(&tctx->xa));sanity check in __io_uring_free() when a io_uring_task is going throughits final put. The syzbot test case includes injecting memory allocationfailures, and it very much looks like xa_store() can fail one of itsmemory allocations and end up with ->head being non-NULL even though noentries exist in the xarray.Until this issue gets sorted out, work around it by attempting toiterate entries in our xarray, and WARN_ON_ONCE() if one is found.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56589 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Add cond_resched() for no forced preemption modelFor no forced preemption model kernel, in the scenario where theexpander is connected to 12 high performance SAS SSDs, the followingcall trace may occur:[ 214.409199][ C240] watchdog: BUG: soft lockup - CPU#240 stuck for 22s! [irq/149-hisi_sa:3211][ 214.568533][ C240] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)[ 214.575224][ C240] pc : fput_many+0x8c/0xdc[ 214.579480][ C240] lr : fput+0x1c/0xf0[ 214.583302][ C240] sp : ffff80002de2b900[ 214.587298][ C240] x29: ffff80002de2b900 x28: ffff1082aa412000[ 214.593291][ C240] x27: ffff3062a0348c08 x26: ffff80003a9f6000[ 214.599284][ C240] x25: ffff1062bbac5c40 x24: 0000000000001000[ 214.605277][ C240] x23: 000000000000000a x22: 0000000000000001[ 214.611270][ C240] x21: 0000000000001000 x20: 0000000000000000[ 214.617262][ C240] x19: ffff3062a41ae580 x18: 0000000000010000[ 214.623255][ C240] x17: 0000000000000001 x16: ffffdb3a6efe5fc0[ 214.629248][ C240] x15: ffffffffffffffff x14: 0000000003ffffff[ 214.635241][ C240] x13: 000000000000ffff x12: 000000000000029c[ 214.641234][ C240] x11: 0000000000000006 x10: ffff80003a9f7fd0[ 214.647226][ C240] x9 : ffffdb3a6f0482fc x8 : 0000000000000001[ 214.653219][ C240] x7 : 0000000000000002 x6 : 0000000000000080[ 214.659212][ C240] x5 : ffff55480ee9b000 x4 : fffffde7f94c6554[ 214.665205][ C240] x3 : 0000000000000002 x2 : 0000000000000020[ 214.671198][ C240] x1 : 0000000000000021 x0 : ffff3062a41ae5b8[ 214.677191][ C240] Call trace:[ 214.680320][ C240] fput_many+0x8c/0xdc[ 214.684230][ C240] fput+0x1c/0xf0[ 214.687707][ C240] aio_complete_rw+0xd8/0x1fc[ 214.692225][ C240] blkdev_bio_end_io+0x98/0x140[ 214.696917][ C240] bio_endio+0x160/0x1bc[ 214.701001][ C240] blk_update_request+0x1c8/0x3bc[ 214.705867][ C240] scsi_end_request+0x3c/0x1f0[ 214.710471][ C240] scsi_io_completion+0x7c/0x1a0[ 214.715249][ C240] scsi_finish_command+0x104/0x140[ 214.720200][ C240] scsi_softirq_done+0x90/0x180[ 214.724892][ C240] blk_mq_complete_request+0x5c/0x70[ 214.730016][ C240] scsi_mq_done+0x48/0xac[ 214.734194][ C240] sas_scsi_task_done+0xbc/0x16c [libsas][ 214.739758][ C240] slot_complete_v3_hw+0x260/0x760 [hisi_sas_v3_hw][ 214.746185][ C240] cq_thread_v3_hw+0xbc/0x190 [hisi_sas_v3_hw][ 214.752179][ C240] irq_thread_fn+0x34/0xa4[ 214.756435][ C240] irq_thread+0xc4/0x130[ 214.760520][ C240] kthread+0x108/0x13c[ 214.764430][ C240] ret_from_fork+0x10/0x18This is because in the hisi_sas driver, both the hardware interrupthandler and the interrupt thread are executed on the same CPU. In theperformance test scenario, function irq_wait_for_interrupt() will alwaysreturn 0 if lots of interrupts occurs and the CPU will be continuouslyconsumed. As a result, the CPU cannot run the watchdog thread. When thewatchdog time exceeds the specified time, call trace occurs.To fix it, add cond_resched() to execute the watchdog thread.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56592 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Call free_htab_elem() after htab_unlock_bucket()For htab of maps, when the map is removed from the htab, it may hold thelast reference of the map. bpf_map_fd_put_ptr() will invokebpf_map_free_id() to free the id of the removed map element. However,bpf_map_fd_put_ptr() is invoked while holding a bucket lock(raw_spin_lock_t), and bpf_map_free_id() attempts to acquire map_idr_lock(spinlock_t), triggering the following lockdep warning: ============================= [ BUG: Invalid wait context ] 6.11.0-rc4+ #49 Not tainted ----------------------------- test_maps/4881 is trying to lock: ffffffff84884578 (map_idr_lock){+...}-{3:3}, at: bpf_map_free_id.part.0+0x21/0x70 other info that might help us debug this: context-{5:5} 2 locks held by test_maps/4881: #0: ffffffff846caf60 (rcu_read_lock){....}-{1:3}, at: bpf_fd_htab_map_update_elem+0xf9/0x270 #1: ffff888149ced148 (&htab->lockdep_key#2){....}-{2:2}, at: htab_map_update_elem+0x178/0xa80 stack backtrace: CPU: 0 UID: 0 PID: 4881 Comm: test_maps Not tainted 6.11.0-rc4+ #49 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), ... Call Trace: dump_stack_lvl+0x6e/0xb0 dump_stack+0x10/0x20 __lock_acquire+0x73e/0x36c0 lock_acquire+0x182/0x450 _raw_spin_lock_irqsave+0x43/0x70 bpf_map_free_id.part.0+0x21/0x70 bpf_map_put+0xcf/0x110 bpf_map_fd_put_ptr+0x9a/0xb0 free_htab_elem+0x69/0xe0 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 htab_map_update_elem+0x50f/0xa80 bpf_fd_htab_map_update_elem+0x131/0x270 bpf_map_update_value+0x266/0x380 __sys_bpf+0x21bb/0x36b0 __x64_sys_bpf+0x45/0x60 x64_sys_call+0x1b2a/0x20d0 do_syscall_64+0x5d/0x100 entry_SYSCALL_64_after_hwframe+0x76/0x7eOne way to fix the lockdep warning is using raw_spinlock_t formap_idr_lock as well. However, bpf_map_alloc_id() invokesidr_alloc_cyclic() after acquiring map_idr_lock, it will trigger asimilar lockdep warning because the slab's lock (s->cpu_slab->lock) isstill a spinlock.Instead of changing map_idr_lock's type, fix the issue by invokinghtab_put_fd_value() after htab_unlock_bucket(). However, only deferringthe invocation of htab_put_fd_value() is not enough, because the old mappointers in htab of maps can not be saved during batched deletion.Therefore, also defer the invocation of free_htab_elem(), so theseto-be-freed elements could be linked together similar to lru map.There are four callers for ->map_fd_put_ptr:(1) alloc_htab_elem() (through htab_put_fd_value())It invokes ->map_fd_put_ptr() under a raw_spinlock_t. The invocation ofhtab_put_fd_value() can not simply move after htab_unlock_bucket(),because the old element has already been stashed in htab->extra_elems.It may be reused immediately after htab_unlock_bucket() and theinvocation of htab_put_fd_value() after htab_unlock_bucket() may releasethe newly-added element incorrectly. Therefore, saving the map pointerof the old element for htab of maps before unlocking the bucket andreleasing the map_ptr after unlock. Beside the map pointer in the oldelement, should do the same thing for the special fields in the oldelement as well.(2) free_htab_elem() (through htab_put_fd_value())Its caller includes __htab_map_lookup_and_delete_elem(),htab_map_delete_elem() and __htab_map_lookup_and_delete_batch().For htab_map_delete_elem(), simply invoke free_htab_elem() afterhtab_unlock_bucket(). For __htab_map_lookup_and_delete_batch(), justlike lru map, linking the to-be-freed element into node_to_free listand invoking free_htab_elem() for these element after unlock. It is safeto reuse batch_flink as the link for node_to_free, because theseelements have been removed from the hash llist.Because htab of maps doesn't support lookup_and_delete operation,__htab_map_lookup_and_delete_elem() doesn't have the problem, so keptit as---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56593 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix oops due to NULL pointer dereference in brcmf_sdiod_sglist_rw()This patch fixes a NULL pointer dereference bug in brcmfmac that occurswhen a high 'sd_sgentry_align' value applies (e.g. 512) and a lot of queued SKBsare sent from the pkt queue.The problem is the number of entries in the pre-allocated sgtable, it isnents = max(rxglom_size, txglom_size) + max(rxglom_size, txglom_size) >> 4 + 1.Given the default [rt]xglom_size=32 it's actually 35 which is too small.Worst case, the pkt queue can end up with 64 SKBs. This occurs when a new SKBis added for each original SKB if tailroom isn't enough to hold tail_pad.At least one sg entry is needed for each SKB. So, eventually the "skb_queue_walk loop"in brcmf_sdiod_sglist_rw may run out of sg entries. This makes sg_next returnNULL and this causes the oops.The patch sets nents to max(rxglom_size, txglom_size) * 2 to be able handlethe worst-case.Btw. this requires only 64-35=29 * 16 (or 20 if CONFIG_NEED_SG_DMA_LENGTH) = 464additional bytes of memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56594 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: set the right AMDGPU sg segment limitationThe driver needs to set the correct max_segment_size;otherwise debug_dma_map_sg() will complain about theover-mapping of the AMDGPU sg length as following:WARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370[ 364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd[ 364.049532] ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii[ 364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G OE 6.10.0-custom #492[ 364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021[ 364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370[ 364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05[ 364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286[ 364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027[ 364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680[ 364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930[ 364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000[ 364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800[ 364.049599] FS: 00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000[ 364.049601] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0[ 364.049605] Call Trace:[ 364.049607] [ 364.049609] ? show_regs+0x6d/0x80[ 364.049614] ? __warn+0x8c/0x140[ 364.049618] ? debug_dma_map_sg+0x2dc/0x370[ 364.049621] ? report_bug+0x193/0x1a0[ 364.049627] ? handle_bug+0x46/0x80[ 364.049631] ? exc_invalid_op+0x1d/0x80[ 364.049635] ? asm_exc_invalid_op+0x1f/0x30[ 364.049642] ? debug_dma_map_sg+0x2dc/0x370[ 364.049647] __dma_map_sg_attrs+0x90/0xe0[ 364.049651] dma_map_sgtable+0x25/0x40[ 364.049654] amdgpu_bo_move+0x59a/0x850 [amdgpu][ 364.049935] ? srso_return_thunk+0x5/0x5f[ 364.049939] ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu][ 364.050095] ttm_bo_handle_move_mem+0xc3/0x180 [ttm][ 364.050103] ttm_bo_validate+0xc1/0x160 [ttm][ 364.050108] ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu][ 364.050263] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu][ 364.050473] kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu][ 364.050680] kfd_ioctl+0x3c2/0x530 [amdgpu][ 364.050866] ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu][ 364.05105---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56595 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add a check to prevent array-index-out-of-bounds in dbAdjTreeWhen the value of lp is 0 at the beginning of the for loop, it willbecome negative in the next assignment and we should bail out.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56596 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in jfs_readdirThe stbl might contain some invalid values. Added a check toreturn error code in that case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56603 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: af_can: do not leave a dangling sk pointer in can_create()On error can_create() frees the allocated sk object, but sock_init_data()has already attached it to the provided sock object. This will leave adangling sk pointer in the sock object and may cause use-after-free later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56606 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_packet: avoid erroring out after sock_init_data() in packet_create()After sock_init_data() the allocated sk object is attached to the providedsock object. On error, packet_create() frees the sk object leaving thedangling pointer in the sock object on return. Some other code may tryto use this pointer and cause use-after-free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56611 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix migrate_to_node() assuming there is at least one VMA in a MMWe currently assume that there is at least one VMA in a MM, which isn'ttrue.So we might end up having find_vma() return NULL, to then de-referenceNULL. So properly handle find_vma() returning NULL.This fixes the report:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 UID: 0 PID: 6021 Comm: syz-executor284 Not tainted 6.12.0-rc7-syzkaller-00187-gf868cd251776 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024RIP: 0010:migrate_to_node mm/mempolicy.c:1090 [inline]RIP: 0010:do_migrate_pages+0x403/0x6f0 mm/mempolicy.c:1194Code: ...RSP: 0018:ffffc9000375fd08 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffc9000375fd78 RCX: 0000000000000000RDX: ffff88807e171300 RSI: dffffc0000000000 RDI: ffff88803390c044RBP: ffff88807e171428 R08: 0000000000000014 R09: fffffbfff2039ef1R10: ffffffff901cf78f R11: 0000000000000000 R12: 0000000000000003R13: ffffc9000375fe90 R14: ffffc9000375fe98 R15: ffffc9000375fdf8FS: 00005555919e1380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555919e1ca8 CR3: 000000007f12a000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: kernel_migrate_pages+0x5b2/0x750 mm/mempolicy.c:1709 __do_sys_migrate_pages mm/mempolicy.c:1727 [inline] __se_sys_migrate_pages mm/mempolicy.c:1723 [inline] __x64_sys_migrate_pages+0x96/0x100 mm/mempolicy.c:1723 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[akpm@linux-foundation.org: add unlikely()]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56614 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: fix OOB map writes when deleting elementsJordy says:"In the xsk_map_delete_elem function an unsigned integer(map->max_entries) is compared with a user-controlled signed integer(k). Due to implicit type conversion, a large unsigned value formap->max_entries can bypass the intended bounds check: if (k >= map->max_entries) return -EINVAL;This allows k to hold a negative value (between -2147483648 and -2),which is then used as an array index in m->xsk_map[k], which resultsin an out-of-bounds access. spin_lock_bh(&m->lock); map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry old_xs = unrcu_pointer(xchg(map_entry, NULL)); // Oob write if (old_xs) xsk_map_sock_delete(old_xs, map_entry); spin_unlock_bh(&m->lock);The xchg operation can then be used to cause an out-of-bounds write.Moreover, the invalid map_entry passed to xsk_map_sock_delete can leadto further memory corruption."It indeed results in following splat:[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108[76612.904330] #PF: supervisor write access in kernel mode[76612.909639] #PF: error_code(0x0002) - not-present page[76612.914855] PGD 0 P4D 0[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0[76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000[76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[76613.041086] PKRU: 55555554[76613.043842] Call Trace:[76613.046331] [76613.048468] ? __die+0x20/0x60[76613.051581] ? page_fault_oops+0x15a/0x450[76613.055747] ? search_extable+0x22/0x30[76613.059649] ? search_bpf_extables+0x5f/0x80[76613.063988] ? exc_page_fault+0xa9/0x140[76613.067975] ? asm_exc_page_fault+0x22/0x30[76613.072229] ? xsk_map_delete_elem+0x2d/0x60[76613.076573] ? xsk_map_delete_elem+0x23/0x60[76613.080914] __sys_bpf+0x19b7/0x23c0[76613.084555] __x64_sys_bpf+0x1a/0x20[76613.088194] do_syscall_64+0x37/0xb0[76613.091832] entry_SYSCALL_64_after_hwframe+0x4b/0x53[76613.096962] RIP: 0033:0x7f80b6d1e88d[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56615 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: fix OOB devmap writes when deleting elementsJordy reported issue against XSKMAP which also applies to DEVMAP - theindex used for accessing map entry, due to being a signed integer,causes the OOB writes. Fix is simple as changing the type from int tou32, however, when compared to XSKMAP case, one more thing needs to beaddressed.When map is released from system via dev_map_free(), we iterate throughall of the entries and an iterator variable is also an int, whichimplies OOB accesses. Again, change it to be u32.Example splat below:[ 160.724676] BUG: unable to handle page fault for address: ffffc8fc2c001000[ 160.731662] #PF: supervisor read access in kernel mode[ 160.736876] #PF: error_code(0x0000) - not-present page[ 160.742095] PGD 0 P4D 0[ 160.744678] Oops: Oops: 0000 [#1] PREEMPT SMP[ 160.749106] CPU: 1 UID: 0 PID: 520 Comm: kworker/u145:12 Not tainted 6.12.0-rc1+ #487[ 160.757050] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[ 160.767642] Workqueue: events_unbound bpf_map_free_deferred[ 160.773308] RIP: 0010:dev_map_free+0x77/0x170[ 160.777735] Code: 00 e8 fd 91 ed ff e8 b8 73 ed ff 41 83 7d 18 19 74 6e 41 8b 45 24 49 8b bd f8 00 00 00 31 db 85 c0 74 48 48 63 c3 48 8d 04 c7 <48> 8b 28 48 85 ed 74 30 48 8b 7d 18 48 85 ff 74 05 e8 b3 52 fa ff[ 160.796777] RSP: 0018:ffffc9000ee1fe38 EFLAGS: 00010202[ 160.802086] RAX: ffffc8fc2c001000 RBX: 0000000080000000 RCX: 0000000000000024[ 160.809331] RDX: 0000000000000000 RSI: 0000000000000024 RDI: ffffc9002c001000[ 160.816576] RBP: 0000000000000000 R08: 0000000000000023 R09: 0000000000000001[ 160.823823] R10: 0000000000000001 R11: 00000000000ee6b2 R12: dead000000000122[ 160.831066] R13: ffff88810c928e00 R14: ffff8881002df405 R15: 0000000000000000[ 160.838310] FS: 0000000000000000(0000) GS:ffff8897e0c40000(0000) knlGS:0000000000000000[ 160.846528] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 160.852357] CR2: ffffc8fc2c001000 CR3: 0000000005c32006 CR4: 00000000007726f0[ 160.859604] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 160.866847] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 160.874092] PKRU: 55555554[ 160.876847] Call Trace:[ 160.879338] [ 160.881477] ? __die+0x20/0x60[ 160.884586] ? page_fault_oops+0x15a/0x450[ 160.888746] ? search_extable+0x22/0x30[ 160.892647] ? search_bpf_extables+0x5f/0x80[ 160.896988] ? exc_page_fault+0xa9/0x140[ 160.900973] ? asm_exc_page_fault+0x22/0x30[ 160.905232] ? dev_map_free+0x77/0x170[ 160.909043] ? dev_map_free+0x58/0x170[ 160.912857] bpf_map_free_deferred+0x51/0x90[ 160.917196] process_one_work+0x142/0x370[ 160.921272] worker_thread+0x29e/0x3b0[ 160.925082] ? rescuer_thread+0x4b0/0x4b0[ 160.929157] kthread+0xd4/0x110[ 160.932355] ? kthread_park+0x80/0x80[ 160.936079] ret_from_fork+0x2d/0x50[ 160.943396] ? kthread_park+0x80/0x80[ 160.950803] ret_from_fork_asm+0x11/0x20[ 160.958482]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56616 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/dp_mst: Fix MST sideband message body length checkFix the MST sideband message body length check, which must be at least 1byte accounting for the message body CRC (aka message data CRC) at theend of the message.This fixes a case where an MST branch device returns a header with acorrect header CRC (indicating a correctly received body length), withthe body length being incorrectly set to 0. This will later lead to amemory corruption in drm_dp_sideband_append_payload() and the followingerrors in dmesg: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25 index -1 is out of range for type 'u8 [48]' Call Trace: drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper] memcpy: detected field-spanning write (size 18446744073709551615) of single field "&msg->msg[msg->curlen]" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256) Call Trace: drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper] drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper] drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: sysfs: Prevent div by zeroPrevent a division by 0 when monitoring is not enabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56629 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: fix when get product name maybe null pointerDue to incorrect dev->product reporting by certain devices, nullpointer dereferences occur when dev->product is empty, leading topotential system crashes.This issue was found on EXCELSIOR DL37-D05 device withLoongson-LS3A6000-7A2000-DL37 motherboard.Kernel logs:[ 56.470885] usb 4-3: new full-speed USB device number 4 using ohci-pci[ 56.671638] usb 4-3: string descriptor 0 read error: -22[ 56.671644] usb 4-3: New USB device found, idVendor=056a, idProduct=0374, bcdDevice= 1.07[ 56.671647] usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 56.678839] hid-generic 0003:056A:0374.0004: hiddev0,hidraw3: USB HID v1.10 Device [HID 056a:0374] on usb-0000:00:05.0-3/input0[ 56.697719] CPU 2 Unable to handle kernel paging request at virtual address 0000000000000000, era == 90000000066e35c8, ra == ffff800004f98a80[ 56.697732] Oops[#1]:[ 56.697734] CPU: 2 PID: 2742 Comm: (udev-worker) Tainted: G OE 6.6.0-loong64-desktop #25.00.2000.015[ 56.697737] Hardware name: Inspur CE520L2/C09901N000000000, BIOS 2.09.00 10/11/2024[ 56.697739] pc 90000000066e35c8 ra ffff800004f98a80 tp 9000000125478000 sp 900000012547b8a0[ 56.697741] a0 0000000000000000 a1 ffff800004818b28 a2 0000000000000000 a3 0000000000000000[ 56.697743] a4 900000012547b8f0 a5 0000000000000000 a6 0000000000000000 a7 0000000000000000[ 56.697745] t0 ffff800004818b2d t1 0000000000000000 t2 0000000000000003 t3 0000000000000005[ 56.697747] t4 0000000000000000 t5 0000000000000000 t6 0000000000000000 t7 0000000000000000[ 56.697748] t8 0000000000000000 u0 0000000000000000 s9 0000000000000000 s0 900000011aa48028[ 56.697750] s1 0000000000000000 s2 0000000000000000 s3 ffff800004818e80 s4 ffff800004810000[ 56.697751] s5 90000001000b98d0 s6 ffff800004811f88 s7 ffff800005470440 s8 0000000000000000[ 56.697753] ra: ffff800004f98a80 wacom_update_name+0xe0/0x300 [wacom][ 56.697802] ERA: 90000000066e35c8 strstr+0x28/0x120[ 56.697806] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)[ 56.697816] PRMD: 0000000c (PPLV0 +PIE +PWE)[ 56.697821] EUEN: 00000000 (-FPE -SXE -ASXE -BTE)[ 56.697827] ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)[ 56.697831] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)[ 56.697835] BADV: 0000000000000000[ 56.697836] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000)[ 56.697838] Modules linked in: wacom(+) bnep bluetooth rfkill qrtr nls_iso8859_1 nls_cp437 snd_hda_codec_conexant snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore input_leds mousedev led_class joydev deepin_netmonitor(OE) fuse nfnetlink dmi_sysfs ip_tables x_tables overlay amdgpu amdxcp drm_exec gpu_sched drm_buddy radeon drm_suballoc_helper i2c_algo_bit drm_ttm_helper r8169 ttm drm_display_helper spi_loongson_pci xhci_pci cec xhci_pci_renesas spi_loongson_core hid_generic realtek gpio_loongson_64bit[ 56.697887] Process (udev-worker) (pid: 2742, threadinfo=00000000aee0d8b4, task=00000000a9eff1f3)[ 56.697890] Stack : 0000000000000000 ffff800004817e00 0000000000000000 0000251c00000000[ 56.697896] 0000000000000000 00000011fffffffd 0000000000000000 0000000000000000[ 56.697901] 0000000000000000 1b67a968695184b9 0000000000000000 90000001000b98d0[ 56.697906] 90000001000bb8d0 900000011aa48028 0000000000000000 ffff800004f9d74c[ 56.697911] 90000001000ba000 ffff800004f9ce58 0000000000000000 ffff800005470440[ 56.697916] ffff800004811f88 90000001000b98d0 9000000100da2aa8 90000001000bb8d0[ 56.697921] 0000000000000000 90000001000ba000 900000011aa48028 ffff800004f9d74c[ 56.697926] ffff8000054704e8 90000001000bb8b8 90000001000ba000 0000000000000000[ 56.697931] 90000001000bb8d0 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56630 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: free inode when ocfs2_get_init_inode() failssyzbot is reporting busy inodes after unmount, for commit 9c89fe0af826("ocfs2: Handle error from dquot_initialize()") forgot to call iput() whennew_inode() succeeded and dquot_initialize() failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56633 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsgThe current sk memory accounting logic in __SK_REDIRECT is pre-unchargingtosend bytes, which is either msg->sg.size or a smaller value apply_bytes.Potential problems with this strategy are as follows:- If the actual sent bytes are smaller than tosend, we need to charge some bytes back, as in line 487, which is okay but seems not clean.- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may miss uncharging (msg->sg.size - apply_bytes) bytes.[...]415 tosend = msg->sg.size;416 if (psock->apply_bytes && psock->apply_bytes < tosend)417 tosend = psock->apply_bytes;[...]443 sk_msg_return(sk, msg, tosend);444 release_sock(sk);446 origsize = msg->sg.size;447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,448 msg, tosend, flags);449 sent = origsize - msg->sg.size;[...]454 lock_sock(sk);455 if (unlikely(ret < 0)) {456 int free = sk_msg_free_nocharge(sk, msg);458 if (!cork)459 *copied -= free;460 }[...]487 if (eval == __SK_REDIRECT)488 sk_mem_charge(sk, tosend - sent);[...]When running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,the following warning will be reported:------------[ cut here ]------------WARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0Modules linked in:CPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014Workqueue: events sk_psock_destroyRIP: 0010:inet_sock_destruct+0x190/0x1a0RSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206RAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800RDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900RBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0R10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400R13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100FS: 0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace:? __warn+0x89/0x130? inet_sock_destruct+0x190/0x1a0? report_bug+0xfc/0x1e0? handle_bug+0x5c/0xa0? exc_invalid_op+0x17/0x70? asm_exc_invalid_op+0x1a/0x20? inet_sock_destruct+0x190/0x1a0__sk_destruct+0x25/0x220sk_psock_destroy+0x2b2/0x310process_scheduled_works+0xa3/0x3e0worker_thread+0x117/0x240? __pfx_worker_thread+0x10/0x10kthread+0xcf/0x100? __pfx_kthread+0x10/0x10ret_from_fork+0x31/0x40? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1a/0x30---[ end trace 0000000000000000 ]---In __SK_REDIRECT, a more concise way is delaying the uncharging after sentbytes are finalized, and uncharge this value. When (ret < 0), we shallinvoke sk_msg_free.Same thing happens in case __SK_DROP, when tosend is set to apply_bytes,we may miss uncharging (msg->sg.size - apply_bytes) bytes. The samewarning will be reported in selftest.[...]468 case __SK_DROP:469 default:470 sk_msg_free_partial(sk, msg, tosend);471 sk_msg_apply_bytes(psock, tosend);472 *copied -= (tosend + delta);473 return -EACCES;[...]So instead of sk_msg_free_partial we can do sk_msg_free here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: grgpio: Add NULL check in grgpio_probedevm_kasprintf() can return a NULL pointer on failure,but thisreturned value in grgpio_probe is not checked.Add NULL check in grgpio_probe, to handle kernel NULLpointer dereference error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix LGR and link use-after-free issueWe encountered a LGR/link use-after-free issue, which manifested asthe LGR/link refcnt reaching 0 early and entering the clear process,making resource access unsafe. refcount_t: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcount_warn_saturate+0x9c/0x140 Workqueue: events smc_lgr_terminate_work [smc] Call trace: refcount_warn_saturate+0x9c/0x140 __smc_lgr_terminate.part.45+0x2a8/0x370 [smc] smc_lgr_terminate_work+0x28/0x30 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118or refcount_t: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcount_warn_saturate+0xf0/0x140 Workqueue: smc_hs_wq smc_listen_work [smc] Call trace: refcount_warn_saturate+0xf0/0x140 smcr_link_put+0x1cc/0x1d8 [smc] smc_conn_free+0x110/0x1b0 [smc] smc_conn_abort+0x50/0x60 [smc] smc_listen_find_device+0x75c/0x790 [smc] smc_listen_work+0x368/0x8a0 [smc] process_one_work+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118It is caused by repeated release of LGR/link refcnt. One suspect is thatsmc_conn_free() is called repeatedly because some smc_conn_free() fromserver listening path are not protected by sock lock.e.g.Calls under socklock | smc_listen_work-------------------------------------------------------lock_sock(sk) | smc_conn_abortsmc_conn_free | \- smc_conn_free\- smcr_link_put | \- smcr_link_put (duplicated)release_sock(sk)So here add sock lock protection in smc_listen_work() path, making itexclusive with other connection operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56641 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: initialize close_work early to avoid warningWe encountered a warning that close_work was canceled beforeinitialization. WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 __flush_work+0x19e/0x1b0 Workqueue: events smc_lgr_terminate_work [smc] RIP: 0010:__flush_work+0x19e/0x1b0 Call Trace: ? __wake_up_common+0x7a/0x190 ? work_busy+0x80/0x80 __cancel_work_timer+0xe3/0x160 smc_close_cancel_work+0x1a/0x70 [smc] smc_close_active_abort+0x207/0x360 [smc] __smc_lgr_terminate.part.38+0xc8/0x180 [smc] process_one_work+0x19e/0x340 worker_thread+0x30/0x370 ? process_one_work+0x340/0x340 kthread+0x117/0x130 ? __kthread_cancel_work+0x50/0x50 ret_from_fork+0x22/0x30This is because when smc_close_cancel_work is triggered, e.g. the RDMAdriver is rmmod and the LGR is terminated, the conn->close_work isflushed before initialization, resulting in WARN_ON(!work->func).__smc_lgr_terminate | smc_connect_{rdma|ism}------------------------------------------------------------- | smc_conn_create | \- smc_lgr_register_connfor conn in lgr->conns_all |\- smc_conn_kill | \- smc_close_active_abort | \- smc_close_cancel_work | \- cancel_work_sync | \- __flush_work | (close_work) | | smc_close_init | \- INIT_WORK(&close_work)So fix this by initializing close_work before establishing theconnection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56647 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix icmp host relookup triggering ip_rt_bugarp link failure may trigger ip_rt_bug while xfrm enabled, call trace is:WARNING: CPU: 0 PID: 0 at net/ipv4/route.c:1241 ip_rt_bug+0x14/0x20Modules linked in:CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.0-rc6-00077-g2e1b3cc9d7f7Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:ip_rt_bug+0x14/0x20Call Trace: ip_send_skb+0x14/0x40 __icmp_send+0x42d/0x6a0 ipv4_link_failure+0xe2/0x1d0 arp_error_report+0x3c/0x50 neigh_invalidate+0x8d/0x100 neigh_timer_handler+0x2e1/0x330 call_timer_fn+0x21/0x120 __run_timer_base.part.0+0x1c9/0x270 run_timer_softirq+0x4c/0x80 handle_softirqs+0xac/0x280 irq_exit_rcu+0x62/0x80 sysvec_apic_timer_interrupt+0x77/0x90The script below reproduces this scenario:ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 \ dir out priority 0 ptype main flag localok icmpip l a veth1 type vethip a a 192.168.141.111/24 dev veth0ip l s veth0 upping 192.168.141.155 -c 1icmp_route_lookup() create input routes for locally generated packetswhile xfrm relookup ICMP traffic.Then it will set input route(dst->out = ip_rt_bug) to skb for DESTUNREACH.For ICMP err triggered by locally generated packets, dst->dev of outputroute is loopback. Generally, xfrm relookup verification is not requiredon loopback interfaces (net.ipv4.conf.lo.disable_xfrm = 1).Skip icmp relookup for locally generated packets to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56657 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: control: Avoid WARN() for symlink errorsUsing WARN() for showing the error of symlink creations don't givemore information than telling that something goes wrong, since theusual code path is a lregister callback from each control elementcreation. More badly, the use of WARN() rather confuses fuzzer as ifit were serious issues.This patch downgrades the warning messages to use the normal dev_err()instead of WARN(). For making it clearer, add the function name tothe prefix, too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56659 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: lapb: increase LAPB_HEADER_LENIt is unclear if net/lapb code is supposed to be ready for 8021q.We can at least avoid crashes like the following :skbuff: skb_under_panic: text:ffffffff8aabe1f6 len:24 put:20 head:ffff88802824a400 data:ffff88802824a3fe tail:0x16 end:0x140 dev:nr0.2------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:206 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 1 UID: 0 PID: 5508 Comm: dhcpcd Not tainted 6.12.0-rc7-syzkaller-00144-g66418447d27b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216Code: 0d 8d 48 c7 c6 2e 9e 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 1a 6f 37 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3RSP: 0018:ffffc90002ddf638 EFLAGS: 00010282RAX: 0000000000000086 RBX: dffffc0000000000 RCX: 7a24750e538ff600RDX: 0000000000000000 RSI: 0000000000000201 RDI: 0000000000000000RBP: ffff888034a86650 R08: ffffffff8174b13c R09: 1ffff920005bbe60R10: dffffc0000000000 R11: fffff520005bbe61 R12: 0000000000000140R13: ffff88802824a400 R14: ffff88802824a3fe R15: 0000000000000016FS: 00007f2a5990d740(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c2631fd CR3: 0000000029504000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 nr_header+0x36/0x320 net/netrom/nr_dev.c:69 dev_hard_header include/linux/netdevice.h:3148 [inline] vlan_dev_hard_header+0x359/0x480 net/8021q/vlan_dev.c:83 dev_hard_header include/linux/netdevice.h:3148 [inline] lapbeth_data_transmit+0x1f6/0x2a0 drivers/net/wan/lapbether.c:257 lapb_data_transmit+0x91/0xb0 net/lapb/lapb_iface.c:447 lapb_transmit_buffer+0x168/0x1f0 net/lapb/lapb_out.c:149 lapb_establish_data_link+0x84/0xd0 lapb_device_event+0x4e0/0x670 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 __dev_notify_flags+0x207/0x400 dev_change_flags+0xf0/0x1a0 net/core/dev.c:8922 devinet_ioctl+0xa4e/0x1aa0 net/ipv4/devinet.c:1188 inet_ioctl+0x3d7/0x4f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x158/0x460 net/socket.c:1227 sock_ioctl+0x626/0x8e0 net/socket.c:1346 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56660 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: DR, prevent potential error pointer dereferenceThe dr_domain_add_vport_cap() function generally returns NULL on errorbut sometimes we want it to return ERR_PTR(-EBUSY) so the caller canretry. The problem here is that "ret" can be either -EBUSY or -ENOMEMand if it's and -ENOMEM then the error pointer is propogated back andeventually dereferenced in dr_ste_v0_build_src_gvmi_qpn_tag().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56688 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transportSince transport->sock has been set to NULL during reset transport,XPRT_SOCK_UPD_TIMEOUT also needs to be cleared. Otherwise, thexs_tcp_set_socket_timeouts() may be triggered in xs_tcp_send_request()to dereference the transport->sock that has been set to NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56698 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix looping of queued SG entriesThe dwc3_request->num_queued_sgs is decremented on completion. If apartially completed request is handled, then thedwc3_request->num_queued_sgs no longer reflects the total number ofnum_queued_sgs (it would be cleared).Correctly check the number of request SG entries remained to be prepareand queued. Failure to do this may cause null pointer dereference whenaccessing non-existent SG entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56701 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix dtl_access_lock to be a rw_semaphoreThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, becausethe code calls kmalloc() while holding it, which can sleep: # echo 1 > /proc/powerpc/vcpudispatch_stats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh preempt_count: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438 #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4 #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dump_stack_lvl+0x130/0x148 (unreliable) __might_resched+0x174/0x410 kmem_cache_alloc_noprof+0x340/0x3d0 alloc_dtl_buffers+0x124/0x1ac vcpudispatch_stats_write+0x2a8/0x5f4 proc_reg_write+0xf4/0x150 vfs_write+0xfc/0x438 ksys_write+0x88/0x148 system_call_exception+0x1c4/0x5a0 system_call_common+0xf4/0x258

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.cAdd error pointer checks after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: check if iowq is killed before queuingtask work can be executed after the task has gone through io_uringtermination, whether it's the final task_work run or the fallback path.In this case, task work will find ->io_wq being already killed andnull'ed, which is a problem if it then tries to forward the request toio_queue_iowq(). Make io_queue_iowq() fail requests in this case.Note that it also checks PF_KTHREAD, because the user can first closea DEFER_TASKRUN ring and shortly after kill the task, in which case->iowq check would race.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ionic: Fix netdev notifier unregister on failureIf register_netdev() fails, then the driver leaks the netdev notifier.Fix this by calling ionic_lif_unregister() on register_netdev()failure. This will also call ionic_lif_unregister_phc() if it hasalready been registered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56716 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: prevent bad user input in nsim_dev_health_break_write()If either a zero count or a large one is provided, kernel can crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56720 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Several fixes to bpf_msg_pop_dataSeveral fixes to bpf_msg_pop_data,1. In sk_msg_shift_left, we should put_page2. if (len == 0), return early is better3. pop the entire sk_msg (last == msg->sg.size) should be supported4. Fix for the value of variable "a"5. In sk_msg_shift_left, after shifting, i has already pointed to the nextelement. Addtional sk_msg_iter_var_next may result in BUG.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56722 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix cpu stuck caused by printings during resetDuring reset, cmd to destroy resources such as qp, cq, and mr may fail,and error logs will be printed. When a large number of resources aredestroyed, there will be lots of printings, and it may lead to a cpustuck.Delete some unnecessary printings and replace other printing functionsin these paths with the ratelimited version.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56723 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devicesWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU deviceWhile design wise the idea of converting the driver to usethe hierarchy of the IRQ chips is correct, the implementationhas (inherited) flaws. This was unveiled when platform_get_irq()had started WARN() on IRQ 0 that is supposed to be a LinuxIRQ number (also known as vIRQ).Rework the driver to respect IRQ domain when creating each MFDdevice separately, as the domain is not the same for all of them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56726 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.cAdding error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56739 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: check if __rtc_read_time was successful in rtc_timer_do_work()If the __rtc_read_time call fails,, the struct rtc_time tm; may containuninitialized data, or an illegal date/time read from the RTC hardware.When calling rtc_tm_to_ktime later, the result may be a very large value(possibly KTIME_MAX). If there are periodic timers in rtc->timerqueue,they will continually expire, may causing kernel softlockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reset_method_store() memory leakIn reset_method_store(), a string is allocated via kstrndup() and assignedto the local "options". options is then used in with strsep() to findspaces: while ((name = strsep(&options, " ")) != NULL) {If there are no remaining spaces, then options is set to NULL by strsep(),so the subsequent kfree(options) doesn't free the memory allocated viakstrndup().Fix by using a separate tmp_options to iterate with strsep() so options ispreserved.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56748 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()Hook "qed_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Prevent bad count for tracing_cpumask_writeIf a large count is provided, it will trigger a warning in bitmap_parse_user.Also check zero for it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56774 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add a sanity check for btrfs root in btrfs_search_slot()Syzbot reports a null-ptr-deref in btrfs_search_slot().The reproducer is using rescue=ibadroots, and the extent tree root iscorrupted thus the extent tree is NULL.When scrub tries to search the extent tree to gather the needed extentinfo, btrfs_search_slot() doesn't check if the target root is NULL ornot, resulting the null-ptr-deref.Add sanity check for btrfs root before using it in btrfs_search_slot().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointersThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56777 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_gdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56778 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sti: avoid potential dereference of error pointers in sti_hqvdp_atomic_checkThe return value of drm_atomic_get_crtc_state() needs to bechecked. To avoid use of error pointer 'crtc_state' in caseof the failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix nfs4_openowner leak when concurrent nfsd4_open occurThe action force umount(umount -f) will attempt to kill all rpc_task evenumount operation may ultimately fail if some files remain open.Consequently, if an action attempts to open a file, it can potentiallysend two rpc_task to nfs server. NFS CLIENTthread1 thread2open("file")...nfs4_do_open _nfs4_do_open _nfs4_open_and_get_state _nfs4_proc_open nfs4_run_open_task /* rpc_task1 */ rpc_run_task rpc_wait_for_completion_task umount -f nfs_umount_begin rpc_killall_tasks rpc_signal_task rpc_task1 been wakeup and return -512 _nfs4_do_open // while loop ... nfs4_run_open_task /* rpc_task2 */ rpc_run_task rpc_wait_for_completion_taskWhile processing an open request, nfsd will first attempt to find orallocate an nfs4_openowner. If it finds an nfs4_openowner that is notmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Sincetwo rpc_task can attempt to open the same file simultaneously from theclient to server, and because two instances of nfsd can runconcurrently, this situation can lead to lots of memory leak.Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will betriggered. NFS SERVERnfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threadsnfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // alloc oo1, stateid1 nfsd4_open nfsd4_process_open1 find_or_alloc_open_stateowner // find oo1, without NFS4_OO_CONFIRMED release_openowner unhash_openowner_locked list_del_init(&oo->oo_perclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2 nfsd4_process_open2 init_open_stateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4_get_vfs_file // alloc nfsd_file1 and nfsd_file_mark1 // all LEAK!!! nfsd4_process_open2 ... write_threads ... nfsd_destroy_serv nfsd_shutdown_net nfs4_state_shutdown_net nfs4_state_destroy_net destroy_client __destroy_client // won't find oo1!!! nfsd_shutdown_generic nfsd_file_cache_shutdown kmem_cache_destroy for nfsd_file_slab and nfsd_file_mark_slab // bark since nfsd_file1 // and nfsd_file_mark1 // still alive=======================================================================BUG nfsd_file (Not tainted): Objects remaining in nfsd_file on__kmem_cache_shutdown()-----------------------------------------------------------------------Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014Call Trace: dum---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: imx8m: Probe the SoC driver as platform driverWith driver_async_probe=* on kernel command line, the following trace isproduced because on i.MX8M Plus hardware because the soc-imx8m.c drivercalls of_clk_get_by_name() which returns -EPROBE_DEFER because the clockdriver is not yet probed. This was not detected during regular testingwithout driver_async_probe.Convert the SoC code to platform driver and instantiate a platform devicein its current device_initcall() to probe the platform driver. Rework.soc_revision callback to always return valid error code and return SoCrevision via parameter. This way, if anything in the .soc_revision callbackreturn -EPROBE_DEFER, it gets propagated to .probe and the .probe will getretried later."------------[ cut here ]------------WARNING: CPU: 1 PID: 1 at drivers/soc/imx/soc-imx8m.c:115 imx8mm_soc_revision+0xdc/0x180CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-next-20240924-00002-g2062bb554dea #603Hardware name: DH electronics i.MX8M Plus DHCOM Premium Developer Kit (3) (DT)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : imx8mm_soc_revision+0xdc/0x180lr : imx8mm_soc_revision+0xd0/0x180sp : ffff8000821fbcc0x29: ffff8000821fbce0 x28: 0000000000000000 x27: ffff800081810120x26: ffff8000818a9970 x25: 0000000000000006 x24: 0000000000824311x23: ffff8000817f42c8 x22: ffff0000df8be210 x21: fffffffffffffdfbx20: ffff800082780000 x19: 0000000000000001 x18: ffffffffffffffffx17: ffff800081fff418 x16: ffff8000823e1000 x15: ffff0000c03b65e8x14: ffff0000c00051b0 x13: ffff800082790000 x12: 0000000000000801x11: ffff80008278ffff x10: ffff80008209d3a6 x9 : ffff80008062e95cx8 : ffff8000821fb9a0 x7 : 0000000000000000 x6 : 00000000000080e3x5 : ffff0000df8c03d8 x4 : 0000000000000000 x3 : 0000000000000000x2 : 0000000000000000 x1 : fffffffffffffdfb x0 : fffffffffffffdfbCall trace: imx8mm_soc_revision+0xdc/0x180 imx8_soc_init+0xb0/0x1e0 do_one_initcall+0x94/0x1a8 kernel_init_freeable+0x240/0x2a8 kernel_init+0x28/0x140 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---SoC: i.MX8MP revision 1.1"

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57807 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: megaraid_sas: Fix for a potential deadlockThis fixes a 'possible circular locking dependency detected' warning CPU0 CPU1 ---- ---- lock(&instance->reset_mutex); lock(&shost->scan_mutex); lock(&instance->reset_mutex); lock(&shost->scan_mutex);Fix this by temporarily releasing the reset_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57809 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: imx6: Fix suspend/resume support on i.MX6QDLThe suspend/resume functionality is currently broken on the i.MX6QDLplatform, as documented in the NXP errata (ERR005723): https://www.nxp.com/docs/en/errata/IMX6DQCE.pdfThis patch addresses the issue by sharing most of the suspend/resumesequences used by other i.MX devices, while avoiding modifications tocritical registers that disrupt the PCIe functionality. It targets thesame problem as the following downstream commit: https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995Unlike the downstream commit, this patch also resets the connected PCIedevice if possible. Without this reset, certain drivers, such as ath10kor iwlwifi, will crash on resume. The device reset is also done by thedriver on other i.MX platforms, making this patch consistent withexisting practices.Upon resuming, the kernel will hang and display an error. Here's anexample of the error encountered with the ath10k driver: ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944Without this patch, suspend/resume will fail on i.MX6QDL devices if aPCIe device is connected.[kwilczynski: commit log, added tag for stable releases]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: Fix a null-ptr-deref in vidtv_mux_stop_threadsyzbot report a null-ptr-deref in vidtv_mux_stop_thread. [1]If dvb->mux is not initialized successfully by vidtv_mux_init() in thevidtv_start_streaming(), it will trigger null pointer dereference about muxin vidtv_mux_stop_thread().Adjust the timing of streaming initialization and check it beforestopping it.[1]KASAN: null-ptr-deref in range [0x0000000000000128-0x000000000000012f]CPU: 0 UID: 0 PID: 5842 Comm: syz-executor248 Not tainted 6.13.0-rc4-syzkaller-00012-g9b2ffa6148b1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024RIP: 0010:vidtv_mux_stop_thread+0x26/0x80 drivers/media/test-drivers/vidtv/vidtv_mux.c:471Code: 90 90 90 90 66 0f 1f 00 55 53 48 89 fb e8 82 2e c8 f9 48 8d bb 28 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 02 7e 3b 0f b6 ab 28 01 00 00 31 ff 89 ee e8RSP: 0018:ffffc90003f2faa8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff87cfb125RDX: 0000000000000025 RSI: ffffffff87d120ce RDI: 0000000000000128RBP: ffff888029b8d220 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000003 R12: ffff888029b8d188R13: ffffffff8f590aa0 R14: ffffc9000581c5c8 R15: ffff888029a17710FS: 00007f7eef5156c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7eef5e635c CR3: 0000000076ca6000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vidtv_stop_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:209 [inline] vidtv_stop_feed+0x151/0x250 drivers/media/test-drivers/vidtv/vidtv_bridge.c:252 dmx_section_feed_stop_filtering+0x90/0x160 drivers/media/dvb-core/dvb_demux.c:1000 dvb_dmxdev_feed_stop.isra.0+0x1ee/0x270 drivers/media/dvb-core/dmxdev.c:486 dvb_dmxdev_filter_stop+0x22a/0x3a0 drivers/media/dvb-core/dmxdev.c:559 dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline] dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246 __fput+0x3f8/0xb60 fs/file_table.c:450 task_work_run+0x14e/0x250 kernel/task_work.c:239 get_signal+0x1d3/0x2610 kernel/signal.c:2790 arch_do_signal_or_restart+0x90/0x7e0 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop kernel/entry/common.c:111 [inline] exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline] syscall_exit_to_user_mode+0x150/0x2a0 kernel/entry/common.c:218 do_syscall_64+0xda/0x250 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57884 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: vmscan: account for free pages to prevent infinite Loop in throttle_direct_reclaim()The task sometimes continues looping in throttle_direct_reclaim() becauseallow_direct_reclaim(pgdat) keeps returning false. #0 [ffff80002cb6f8d0] __switch_to at ffff8000080095ac #1 [ffff80002cb6f900] __schedule at ffff800008abbd1c #2 [ffff80002cb6f990] schedule at ffff800008abc50c #3 [ffff80002cb6f9b0] throttle_direct_reclaim at ffff800008273550 #4 [ffff80002cb6fa20] try_to_free_pages at ffff800008277b68 #5 [ffff80002cb6fae0] __alloc_pages_nodemask at ffff8000082c4660 #6 [ffff80002cb6fc50] alloc_pages_vma at ffff8000082e4a98 #7 [ffff80002cb6fca0] do_anonymous_page at ffff80000829f5a8 #8 [ffff80002cb6fce0] __handle_mm_fault at ffff8000082a5974 #9 [ffff80002cb6fd90] handle_mm_fault at ffff8000082a5bd4At this point, the pgdat contains the following two zones: NODE: 4 ZONE: 0 ADDR: ffff00817fffe540 NAME: "DMA32" SIZE: 20480 MIN/LOW/HIGH: 11/28/45 VM_STAT: NR_FREE_PAGES: 359 NR_ZONE_INACTIVE_ANON: 18813 NR_ZONE_ACTIVE_ANON: 0 NR_ZONE_INACTIVE_FILE: 50 NR_ZONE_ACTIVE_FILE: 0 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0 NODE: 4 ZONE: 1 ADDR: ffff00817fffec00 NAME: "Normal" SIZE: 8454144 PRESENT: 98304 MIN/LOW/HIGH: 68/166/264 VM_STAT: NR_FREE_PAGES: 146 NR_ZONE_INACTIVE_ANON: 94668 NR_ZONE_ACTIVE_ANON: 3 NR_ZONE_INACTIVE_FILE: 735 NR_ZONE_ACTIVE_FILE: 78 NR_ZONE_UNEVICTABLE: 0 NR_ZONE_WRITE_PENDING: 0 NR_MLOCK: 0 NR_BOUNCE: 0 NR_ZSPAGES: 0 NR_FREE_CMA_PAGES: 0In allow_direct_reclaim(), while processing ZONE_DMA32, the sum ofinactive/active file-backed pages calculated in zone_reclaimable_pages()based on the result of zone_page_state_snapshot() is zero. Additionally, since this system lacks swap, the calculation of inactive/active anonymous pages is skipped. crash> p nr_swap_pages nr_swap_pages = $1937 = { counter = 0 }As a result, ZONE_DMA32 is deemed unreclaimable and skipped, moving on tothe processing of the next zone, ZONE_NORMAL, despite ZONE_DMA32 havingfree pages significantly exceeding the high watermark.The problem is that the pgdat->kswapd_failures hasn't been incremented. crash> px ((struct pglist_data *) 0xffff00817fffe540)->kswapd_failures $1935 = 0x0This is because the node deemed balanced. The node balancing logic inbalance_pgdat() evaluates all zones collectively. If one or more zones(e.g., ZONE_DMA32) have enough free pages to meet their watermarks, theentire node is deemed balanced. This causes balance_pgdat() to exit earlybefore incrementing the kswapd_failures, as it considers the overallmemory state acceptable, even though some zones (like ZONE_NORMAL) remainunder significant pressure.The patch ensures that zone_reclaimable_pages() includes free pages(NR_FREE_PAGES) in its calculation when no other reclaimable pages areavailable (e.g., file-backed or anonymous pages). This change preventszones like ZONE_DMA32, which have sufficient free pages, from beingmistakenly deemed unreclaimable. By doing so, the patch ensures propernode balancing, avoids masking pressure on other zones like ZONE_NORMAL,and prevents infinite loops in throttle_direct_reclaim() caused byallow_direct_reclaim(pgdat) repeatedly returning false.The kernel hangs due to a task stuck in throttle_direct_reclaim(), causedby a node being incorrectly deemed balanced despite pressure in certainzones, such as ZONE_NORMAL. This issue arises fromzone_reclaimable_pages---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57888 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:workqueue: Do not warn when cancelling WQ_MEM_RECLAIM work from !WQ_MEM_RECLAIM workerAfter commit746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")amdgpu started seeing the following warning: [ ] workqueue: WQ_MEM_RECLAIM sdma0:drm_sched_run_job_work [gpu_sched] is flushing !WQ_MEM_RECLAIM events:amdgpu_device_delay_enable_gfx_off [amdgpu]... [ ] Workqueue: sdma0 drm_sched_run_job_work [gpu_sched]... [ ] Call Trace: [ ] ... [ ] ? check_flush_dependency+0xf5/0x110... [ ] cancel_delayed_work_sync+0x6e/0x80 [ ] amdgpu_gfx_off_ctrl+0xab/0x140 [amdgpu] [ ] amdgpu_ring_alloc+0x40/0x50 [amdgpu] [ ] amdgpu_ib_schedule+0xf4/0x810 [amdgpu] [ ] ? drm_sched_run_job_work+0x22c/0x430 [gpu_sched] [ ] amdgpu_job_run+0xaa/0x1f0 [amdgpu] [ ] drm_sched_run_job_work+0x257/0x430 [gpu_sched] [ ] process_one_work+0x217/0x720... [ ] The intent of the verifcation done in check_flush_depedency is to ensureforward progress during memory reclaim, by flagging cases when either amemory reclaim process, or a memory reclaim work item is flushed from acontext not marked as memory reclaim safe.This is correct when flushing, but when called from thecancel(_delayed)_work_sync() paths it is a false positive because work iseither already running, or will not be running at all. Thereforecancelling it is safe and we can relax the warning criteria by letting thehelper know of the calling context.References: 746ae46c1113 ("drm/sched: Mark scheduler work queues with WQ_MEM_RECLAIM")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57889 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: mcp23s08: Fix sleeping in atomic context due to regmap lockingIf a device uses MCP23xxx IO expander to receive IRQs, the followingbug can happen: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:283 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, ... preempt_count: 1, expected: 0 ... Call Trace: ... __might_resched+0x104/0x10e __might_sleep+0x3e/0x62 mutex_lock+0x20/0x4c regmap_lock_mutex+0x10/0x18 regmap_update_bits_base+0x2c/0x66 mcp23s08_irq_set_type+0x1ae/0x1d6 __irq_set_trigger+0x56/0x172 __setup_irq+0x1e6/0x646 request_threaded_irq+0xb6/0x160 ...We observed the problem while experimenting with a touchscreen driver whichused MCP23017 IO expander (I2C).The regmap in the pinctrl-mcp23s08 driver uses a mutex for protection fromconcurrent accesses, which is the default for regmaps without .fast_io,.disable_locking, etc.mcp23s08_irq_set_type() calls regmap_update_bits_base(), and the latterlocks the mutex.However, __setup_irq() locks desc->lock spinlock before calling thesefunctions. As a result, the system tries to lock the mutex whole holdingthe spinlock.It seems, the internal regmap locks are not needed in this driver at all.mcp->lock seems to protect the regmap from concurrent accesses already,except, probably, in mcp_pinconf_get/set.mcp23s08_irq_set_type() and mcp23s08_irq_mask/unmask() are called underchip_bus_lock(), which calls mcp23s08_irq_bus_lock(). The latter takesmcp->lock and enables regmap caching, so that the potentially slow I2Caccesses are deferred until chip_bus_unlock().The accesses to the regmap from mcp23s08_probe_one() do not need additionallocking.In all remaining places where the regmap is accessed, exceptmcp_pinconf_get/set(), the driver already takes mcp->lock.This patch adds locking in mcp_pinconf_get/set() and disables internallocking in the regmap config. Among other things, it fixes the sleepingin atomic context described above.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57892 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix slab-use-after-free due to dangling pointer dqi_privWhen mounting ocfs2 and then remounting it as read-only, aslab-use-after-free occurs after the user uses a syscall toquota_getnextquota. Specifically, sb_dqinfo(sb, type)->dqi_priv is thedangling pointer.During the remounting process, the pointer dqi_priv is freed but is neverset as null leaving it to be accessed. Additionally, the read-only optionfor remounting sets the DQUOT_SUSPENDED flag instead of setting theDQUOT_USAGE_ENABLED flags. Moreover, later in the process of getting thenext quota, the function ocfs2_get_next_id is called and only checks thequota usage flags and not the quota suspended flags.To fix this, I set dqi_priv to null when it is freed after remounting withread-only and put a check for DQUOT_SUSPENDED in ocfs2_get_next_id.[akpm@linux-foundation.org: coding-style cleanups]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57896 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: flush delalloc workers queue before stopping cleaner kthread during unmountDuring the unmount path, at close_ctree(), we first stop the cleanerkthread, using kthread_stop() which frees the associated task_struct, andthen stop and destroy all the work queues. However after we stopped thecleaner we may still have a worker from the delalloc_workers queue runninginode.c:submit_compressed_extents(), which calls btrfs_add_delayed_iput(),which in turn tries to wake up the cleaner kthread - which was alreadydestroyed before, resulting in a use-after-free on the task_struct.Syzbot reported this with the following stack traces: BUG: KASAN: slab-use-after-free in __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 Read of size 8 at addr ffff8880259d2818 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.13.0-rc1-syzkaller-00002-gcdd30ebb1b9f #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-delalloc btrfs_work_helper Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 __lock_acquire+0x78/0x2100 kernel/locking/lockdep.c:5089 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xc2/0x1470 kernel/sched/core.c:4205 submit_compressed_extents+0xdf/0x16e0 fs/btrfs/inode.c:1615 run_ordered_work fs/btrfs/async-thread.c:288 [inline] btrfs_work_helper+0x96f/0xc40 fs/btrfs/async-thread.c:324 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:250 [inline] slab_post_alloc_hook mm/slub.c:4104 [inline] slab_alloc_node mm/slub.c:4153 [inline] kmem_cache_alloc_node_noprof+0x1d9/0x380 mm/slub.c:4205 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1113 copy_process+0x5d1/0x3d50 kernel/fork.c:2225 kernel_clone+0x223/0x870 kernel/fork.c:2807 kernel_thread+0x1bc/0x240 kernel/fork.c:2869 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:767 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 24: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2338 [inline] slab_free mm/slub.c:4598 [inline] kmem_cache_free+0x195/0x410 mm/slub.c:4700 put_task_struct include/linux/sched/task.h:144 [inline] delayed_put_task_struct+0x125/0x300 kernel/exit.c:227 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:554 run_ksoftirqd+0xca/0x130 kernel/softirq.c:943 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57903 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: restrict SO_REUSEPORT to inet socketsAfter blamed commit, crypto sockets could accidentally be destroyedfrom RCU call back, as spotted by zyzbot [1].Trying to acquire a mutex in RCU callback is not allowed.Restrict SO_REUSEPORT socket option to inet sockets.v1 of this patch supported TCP, UDP and SCTP sockets,but fcnal-test.sh test needed RAW and ICMP support.[1]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:562in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 24, name: ksoftirqd/1preempt_count: 100, expected: 0RCU nest depth: 0, expected: 01 lock held by ksoftirqd/1/24: #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline] #0: ffffffff8e937ba0 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823Preemption disabled at: [] softirq_handle_begin kernel/softirq.c:402 [inline] [] handle_softirqs+0x128/0x9b0 kernel/softirq.c:537CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.13.0-rc3-syzkaller-00174-ga024e377efed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 __might_resched+0x5d4/0x780 kernel/sched/core.c:8758 __mutex_lock_common kernel/locking/mutex.c:562 [inline] __mutex_lock+0x131/0xee0 kernel/locking/mutex.c:735 crypto_put_default_null_skcipher+0x18/0x70 crypto/crypto_null.c:179 aead_release+0x3d/0x50 crypto/algif_aead.c:489 alg_do_release crypto/af_alg.c:118 [inline] alg_sock_destruct+0x86/0xc0 crypto/af_alg.c:502 __sk_destruct+0x58/0x5f0 net/core/sock.c:2260 rcu_do_batch kernel/rcu/tree.c:2567 [inline] rcu_core+0xaaa/0x17a0 kernel/rcu/tree.c:2823 handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561 run_ksoftirqd+0xca/0x130 kernel/softirq.c:950 smpboot_thread_fn+0x544/0xa30 kernel/smpboot.c:164 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57922 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add check for granularity in dml ceil/floor helpers[Why]Wrapper functions for dcn_bw_ceil2() and dcn_bw_floor2()should check for granularity is non zero to avoid assert anddivide-by-zero error in dcn_bw_ functions.[How]Add check for granularity 0.(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57924 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: relax assertions on failure to encode file handlesEncoding file handles is usually performed by a filesystem >encode_fh()method that may fail for various reasons.The legacy users of exportfs_encode_fh(), namely, nfsd andname_to_handle_at(2) syscall are ready to cope with the possibilityof failure to encode a file handle.There are a few other users of exportfs_encode_{fh,fid}() thatcurrently have a WARN_ON() assertion when ->encode_fh() fails.Relax those assertions because they are wrong.The second linked bug report states commit 16aac5ad1fa9 ("ovl: supportencoding non-decodable file handles") in v6.6 as the regressing commit,but this is not accurate.The aforementioned commit only increases the chances of the assertionand allows triggering the assertion with the reproducer using overlayfs,inotify and drop_caches.Triggering this assertion was always possible with other filesystems andother reasons of ->encode_fh() failures and more particularly, it wasalso possible with the exact same reproducer using overlayfs that ismounted with options index=on,nfs_export=on also on kernels < v6.6.Therefore, I am not listing the aforementioned commit as a Fixes commit.Backport hint: this patch will have a trivial conflict applying tov6.6.y, and other trivial conflicts applying to stable kernels < v6.6.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:selinux: ignore unknown extended permissionsWhen evaluating extended permissions, ignore unknown permissions insteadof calling BUG(). This commit ensures that future permissions can beadded without interfering with older kernels.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57932 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XDP xmit NDO on existence of xdp queuesIn GVE, dedicated XDP queues only exist when an XDP program is installedand the interface is up. As such, the NDO XDP XMIT callback shouldreturn early if either of these conditions are false.In the case of no loaded XDP program, priv->num_xdp_queues=0 which cancause a divide-by-zero error, and in the case of interface down,num_xdp_queues remains untouched to persist XDP queue count for the nextinterface up, but the TX pointer itself would be NULL.The XDP xmit callback also needs to synchronize with a devicetransitioning from open to close. This synchronization will happen viathe GVE_PRIV_FLAGS_NAPI_ENABLED bit along with a synchronize_net() call,which waits for any RCU critical sections at call-time to complete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57933 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: guard XSK operations on the existence of queuesThis patch predicates the enabling and disabling of XSK pools on theexistence of queues. As it stands, if the interface is down, disablingor enabling XSK pools would result in a crash, as the RX queue pointerwould be NULL. XSK pool registration will occur as part of the nextinterface up.Similarly, xsk_wakeup needs be guarded against queues disappearingwhile the function is executing, so a check against theGVE_PRIV_FLAGS_NAPI_ENABLED flag is added to synchronize with thedisabling of the bit and the synchronize_net() in gve_turndown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: Prevent autoclose integer overflow in sctp_association_init()While by default max_autoclose equals to INT_MAX / HZ, one may setnet.sctp.max_autoclose to UINT_MAX. There is code insctp_association_init() that can consequently trigger overflow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57973 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rdma/cxgb4: Prevent potential integer overflow on 32bitThe "gl->tot_len" variable is controlled by the user. It comes fromprocess_responses(). On 32bit systems, the "gl->tot_len + sizeof(structcpl_pass_accept_req) + sizeof(struct rss_header)" addition could have aninteger wrapping bug. Use size_add() to prevent this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57974 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Deal with race between UDP socket address change and rehashIf a UDP socket changes its local address while it's receivingdatagrams, as a result of connect(), there is a period during whicha lookup operation might fail to find it, after the address is changedbut before the secondary hash (port and address) and the four-tuplehash (local and remote ports and addresses) are updated.Secondary hash chains were introduced by commit 30fff9231fad ("udp:bind() optimisation") and, as a result, a rehash operation becameneeded to make a bound socket reachable again after a connect().This operation was introduced by commit 719f835853a9 ("udp: addrehash on connect()") which isn't however a complete fix: thesocket will be found once the rehashing completes, but not whileit's pending.This is noticeable with a socat(1) server in UDP4-LISTEN mode, and aclient sending datagrams to it. After the server receives the firstdatagram (cf. _xioopen_ipdgram_listen()), it issues a connect() tothe address of the sender, in order to set up a directed flow.Now, if the client, running on a different CPU thread, happens tosend a (subsequent) datagram while the server's socket changes itsaddress, but is not rehashed yet, this will result in a failedlookup and a port unreachable error delivered to the client, asapparent from the following reproducer: LEN=$(($(cat /proc/sys/net/core/wmem_default) / 4)) dd if=/dev/urandom bs=1 count=${LEN} of=tmp.in while :; do taskset -c 1 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.1 || sleep 1 taskset -c 2 socat OPEN:tmp.in UDP4:localhost:1337,shut-null wait donewhere the client will eventually get ECONNREFUSED on a write()(typically the second or third one of a given iteration): 2024/11/13 21:28:23 socat[46901] E write(6, 0x556db2e3c000, 8192): Connection refusedThis issue was first observed as a seldom failure in Podman's testschecking UDP functionality while using pasta(1) to connect thecontainer's network namespace, which leads us to a reproducer withthe lookup error resulting in an ICMP packet on a tap device: LOCAL_ADDR="$(ip -j -4 addr show|jq -rM '.[] | .addr_info[0] | select(.scope == "global").local')" while :; do ./pasta --config-net -p pasta.pcap -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,trunc & sleep 0.2 || sleep 1 socat OPEN:tmp.in UDP4:${LOCAL_ADDR}:1337,shut-null wait cmp tmp.in tmp.out doneOnce this fails: tmp.in tmp.out differ: char 8193, line 29we can finally have a look at what's going on: $ tshark -r pasta.pcap 1 0.000000 :: ? ff02::16 ICMPv6 110 Multicast Listener Report Message v2 2 0.168690 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 3 0.168767 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 4 0.168806 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 5 0.168827 c6:47:05:8d:dc:04 ? Broadcast ARP 42 Who has 88.198.0.161? Tell 88.198.0.164 6 0.168851 9a:55:9a:55:9a:55 ? c6:47:05:8d:dc:04 ARP 42 88.198.0.161 is at 9a:55:9a:55:9a:55 7 0.168875 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 8 0.168896 88.198.0.164 ? 88.198.0.161 ICMP 590 Destination unreachable (Port unreachable) 9 0.168926 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 10 0.168959 88.198.0.161 ? 88.198.0.164 UDP 8234 60260 ? 1337 Len=8192 11 0.168989 88.198.0.161 ? 88.198.0.164 UDP 4138 60260 ? 1337 Len=4096 12 0.169010 88.198.0.161 ? 88.198.0.164 UDP 42 60260 ? 1337 Len=0On the third datagram received, the network namespace of the containerinitiates an ARP lookup to deliver the ICMP message.In another variant of this reproducer, starting the client with: strace -f pasta --config-net -u 1337 socat UDP4-LISTEN:1337,null-eof OPEN:tmp.out,create,tru---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57979 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pps: Fix a use-after-freeOn a board running ntpd and gpsd, I'm seeing a consistent use-after-freein sys_exit() from gpsd when rebooting: pps pps1: removed ------------[ cut here ]------------ kobject: '(null)' (00000000db4bec24): is not initialized, yet kobject_put() is being called. WARNING: CPU: 2 PID: 440 at lib/kobject.c:734 kobject_put+0x120/0x150 CPU: 2 UID: 299 PID: 440 Comm: gpsd Not tainted 6.11.0-rc6-00308-gb31c44928842 #1 Hardware name: Raspberry Pi 4 Model B Rev 1.1 (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : kobject_put+0x120/0x150 lr : kobject_put+0x120/0x150 sp : ffffffc0803d3ae0 x29: ffffffc0803d3ae0 x28: ffffff8042dc9738 x27: 0000000000000001 x26: 0000000000000000 x25: ffffff8042dc9040 x24: ffffff8042dc9440 x23: ffffff80402a4620 x22: ffffff8042ef4bd0 x21: ffffff80405cb600 x20: 000000000008001b x19: ffffff8040b3b6e0 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 696e6920746f6e20 x14: 7369203a29343263 x13: 205d303434542020 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: kobject_put+0x120/0x150 cdev_put+0x20/0x3c __fput+0x2c4/0x2d8 ____fput+0x1c/0x38 task_work_run+0x70/0xfc do_exit+0x2a0/0x924 do_group_exit+0x34/0x90 get_signal+0x7fc/0x8c0 do_signal+0x128/0x13b4 do_notify_resume+0xdc/0x160 el0_svc+0xd4/0xf8 el0t_64_sync_handler+0x140/0x14c el0t_64_sync+0x190/0x194 ---[ end trace 0000000000000000 ]---...followed by more symptoms of corruption, with similar stacks: refcount_t: underflow; use-after-free. kernel BUG at lib/list_debug.c:62! Kernel panic - not syncing: Oops - BUG: Fatal exceptionThis happens because pps_device_destruct() frees the pps_device with theembedded cdev immediately after calling cdev_del(), but, as the commentabove cdev_del() notes, fops for previously opened cdevs are stillcallable even after cdev_del() returns. I think this bug has alwaysbeen there: I can't explain why it suddenly started happening every timeI reboot this particular board.In commit d953e0e837e6 ("pps: Fix a use-after free bug whenunregistering a source."), George Spelvin suggested removing theembedded cdev. That seems like the simplest way to fix this, so I'veimplemented his suggestion, using __register_chrdev() with pps_idrbecoming the source of truth for which minor corresponds to whichdevice.But now that pps_idr defines userspace visibility instead of cdev_add(),we need to be sure the pps->dev refcount can't reach zero whileuserspace can still find it again. So, the idr_remove() call moves topps_unregister_cdev(), and pps_idr now holds a reference to pps->dev. pps_core: source serial1 got cdev (251:1) <...> pps pps1: removed pps_core: unregistering pps1 pps_core: deallocating pps1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix double free in error pathIf the uvc_status_init() function fails to allocate the int_urb, it willfree the dev->status pointer but doesn't reset the pointer to NULL. Thisresults in the kfree() call in uvc_status_cleanup() trying todouble-free the memory. Fix it by resetting the dev->status pointer toNULL after freeing it.Reviewed by: Ricardo Ribalda

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57981 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Fix NULL pointer dereference on certain command abortsIf a command is queued to the final usable TRB of a ring segment, theenqueue pointer is advanced to the subsequent link TRB and no further.If the command is later aborted, when the abort completion is handledthe dequeue pointer is advanced to the first TRB of the next segment.If no further commands are queued, xhci_handle_stopped_cmd_ring() seesthe ring pointers unequal and assumes that there is a pending command,so it calls xhci_mod_cmd_timer() which crashes if cur_cmd was NULL.Don't attempt timer setup if cur_cmd is NULL. The subsequent doorbellring likely is unnecessary too, but it's harmless. Leave it alone.This is probably Bug 219532, but no confirmation has been received.The issue has been independently reproduced and confirmed fixed usinga USB MCU programmed to NAK the Status stage of SET_ADDRESS forever.Everything continued working normally after several prevented crashes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: state: fix out-of-bounds read during lookuplookup and resize can run in parallel.The xfrm_state_hash_generation seqlock ensures a retry, but the hashfunctions can observe a hmask value that is too large for the new hlistarray.rehash does: rcu_assign_pointer(net->xfrm.state_bydst, ndst) [..] net->xfrm.state_hmask = nhashmask;While state lookup does: h = xfrm_dst_hash(net, daddr, saddr, tmpl->reqid, encap_family); hlist_for_each_entry_rcu(x, net->xfrm.state_bydst + h, bydst) {This is only safe in case the update to state_bydst is larger thannet->xfrm.xfrm_state_hmask (or if the lookup function getsserialized via state spinlock again).Fix this by prefetching state_hmask and the associated pointers.The xfrm_state_hash_generation seqlock retry will ensure that the pointerand the hmask will be consistent.The existing helpers, like xfrm_dst_hash(), are now unsafe for RCU side,add lockdep assertions to document that they are only safe for insertside.xfrm_state_lookup_byaddr() uses the spinlock rather than RCU.AFAICS this is an oversight from back when state lookup was converted toRCU, this lock should be replaced with RCU in a future patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57986 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: core: Fix assumption that Resolution Multipliers must be in Logical CollectionsA report in 2019 by the syzbot fuzzer was found to be connected to twoerrors in the HID core associated with Resolution Multipliers. One ofthe errors was fixed by commit ea427a222d8b ("HID: core: Fix deadloopin hid_apply_multiplier."), but the other has not been fixed.This error arises because hid_apply_multipler() assumes that everyResolution Multiplier control is contained in a Logical Collection,i.e., there's no way the routine can ever set multiplier_collection toNULL. This is in spite of the fact that the function starts with abig comment saying: * "The Resolution Multiplier control must be contained in the same * Logical Collection as the control(s) to which it is to be applied. ... * If no Logical Collection is * defined, the Resolution Multiplier is associated with all * controls in the report." * HID Usage Table, v1.12, Section 4.3.1, p30 * * Thus, search from the current collection upwards until we find a * logical collection...The comment and the code overlook the possibility that none of thecollections found may be a Logical Collection.The fix is to set the multiplier_collection pointer to NULL if thecollection found isn't a Logical Collection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-thrustmaster: Fix warning in thrustmaster_probe by adding endpoint checksyzbot has found a type mismatch between a USB pipe and the transferendpoint, which is triggered by the hid-thrustmaster driver[1].There is a number of similar, already fixed issues [2].In this case as in others, implementing check for endpoint type fixes the issue.[1] https://syzkaller.appspot.com/bug?extid=040e8b3db6a96908d470[2] https://syzkaller.appspot.com/bug?extid=348331f63b034f89b622

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58002 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Remove dangling pointersWhen an async control is written, we copy a pointer to the file handlethat started the operation. That pointer will be used when the device isdone. Which could be anytime in the future.If the user closes that file descriptor, its structure will be freed,and there will be one dangling pointer per pending async control, thatthe driver will try to use.Clean all the dangling pointers during release().To avoid adding a performance penalty in the most common case (no asyncoperation), a counter has been introduced with some logic to make surethat it is properly handled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Change to kvalloc() in eventlog/acpi.cThe following failure was reported on HPE ProLiant D320:[ 10.693310][ T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)[ 10.848132][ T1] ------------[ cut here ]------------[ 10.853559][ T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330[ 10.862827][ T1] Modules linked in:[ 10.866671][ T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375[ 10.882741][ T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024[ 10.892170][ T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330[ 10.898103][ T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1[ 10.917750][ T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246[ 10.923777][ T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000[ 10.931727][ T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0The above transcript shows that ACPI pointed a 16 MiB buffer for the logevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().Address the bug by moving from devm_kmalloc() to devm_add_action() andkvmalloc() and devm_add_action().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: socinfo: Avoid out of bounds read of serial numberOn MSM8916 devices, the serial number exposed in sysfs is constant and doesnot change across individual devices. It's always: db410c:/sys/devices/soc0$ cat serial_number 2644893864The firmware used on MSM8916 exposes SOCINFO_VERSION(0, 8), which does nothave support for the serial_num field in the socinfo struct. There is anexisting check to avoid exposing the serial number in that case, but it'snot correct: When checking the item_size returned by SMEM, we need to makesure the *end* of the serial_num is within bounds, instead of comparingwith the *start* offset. The serial_number currently exposed on MSM8916devices is just an out of bounds read of whatever comes after the socinfostruct in SMEM.Fix this by changing offsetof() to offsetofend(), so that the size of thefield is also taken into account.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58009 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: handle NULL sock pointer in l2cap_sock_allocA NULL sock pointer is passed into l2cap_sock_alloc() when it is calledfrom l2cap_sock_new_connection_cb() and the error handling paths shouldalso be aware of it.Seemingly a more elegant solution would be to swap bt_sock_alloc() andl2cap_chan_create() calls since they are not interdependent to that momentbut then l2cap_chan_create() adds the soon to be deallocated and stilldummy-initialized channel to the global list accessible by many L2CAPpaths. The channel would be removed from the list in short period of timebut be a bit more straight-forward here and just check for NULL instead ofchanging the order of function calls.Found by Linux Verification Center (linuxtesting.org) with SVACE staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: int3472: Check for adev == NULLNot all devices have an ACPI companion fwnode, so adev might be NULL. Thiscan e.g. (theoretically) happen when a user manually binds one ofthe int3472 drivers to another i2c/platform device through sysfs.Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in skl_int3472_get_acpi_buffer().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58034 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:memory: tegra20-emc: fix an OF node reference bug in tegra_emc_find_node_by_ram_code()As of_find_node_by_name() release the reference of the argument devicenode, tegra_emc_find_node_by_ram_code() releases some device nodes whilestill in use, resulting in possible UAFs. According to the bindings andthe in-tree DTS files, the "emc-tables" node is always device's childnode with the property "nvidia,use-ram-code", and the "lpddr2" node is achild of the "emc-tables" node. Thus utilize thefor_each_child_of_node() macro and of_get_child_by_name() instead ofof_find_node_by_name() to simplify the code.This bug was found by an experimental verification tool that I amdeveloping.[krzysztof: applied v1, adjust the commit msg to incorporate v2 parts]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi: ipmb: Add check devm_kasprintf() returned valuedevm_kasprintf() can return a NULL pointer on failure but thisreturned value is not checked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential NULL pointer dereference in atomctrl_get_smc_sclk_range_tableThe function atomctrl_get_smc_sclk_range_table() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table() fails toretrieve SMU_Info table, it returns NULL which is later dereferenced.Found by Linux Verification Center (linuxtesting.org) with SVACE.In practice this should never happen as this code only gets calledon polaris chips and the vbios data table will always be present onthose chips.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix handling of received connection abortFix the handling of a connection abort that we've received. Though theabort is at the connection level, it needs propagating to the calls on thatconnection. Whilst the propagation bit is performed, the calls aren't thenwoken up to go and process their termination, and as no further input isforthcoming, they just hang.Also add some tracing for the logging of connection aborts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_tcm: Don't free command immediatelyDon't prematurely free the command. Wait for the status completion ofthe sense status. It can be freed then. Otherwise we will double-freethe command.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert workqueues to unboundWhen a workqueue is created with `WQ_UNBOUND`, its work items areserved by special worker-pools, whose host workers are not bound toany specific CPU. In the default configuration (i.e. when`queue_delayed_work` and friends do not specify which CPU to run thework item on), `WQ_UNBOUND` allows the work item to be executed on anyCPU in the same node of the CPU it was enqueued on. While thissolution potentially sacrifices locality, it avoids contention withother processes that might dominate the CPU time of the processor thework item was scheduled on.This is not just a theoretical problem: in a particular scenariomisconfigured process was hogging most of the time from CPU0, leavingless than 0.5% of its CPU time to the kworker. The IDPF workqueuesthat were using the kworker on CPU0 suffered large completion delaysas a result, causing performance degradation, timeouts and eventualsystem crash.* I have also run a manual test to gauge the performance improvement. The test consists of an antagonist process (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This process is run under `taskset 01` to bind it to CPU0, and its priority is changed with `chrt -pQ 9900 10000 ${pid}` and `renice -n -20 ${pid}` after start. Then, the IDPF driver is forced to prefer CPU0 by editing all calls to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0. Finally, `ktraces` for the workqueue events are collected. Without the current patch, the antagonist process can force arbitrary delays between `workqueue_queue_work` and `workqueue_execute_start`, that in my tests were as high as `30ms`. With the current patch applied, the workqueue can be migrated to another unloaded CPU in the same node, and, keeping everything else equal, the maximum delay I could see was `6us`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58058 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: skip dumping tnc tree when zroot is nullClearing slab cache will free all znode in memory and makec->zroot.znode = NULL, then dumping tnc tree will accessc->zroot.znode which cause null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58063 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: fix memory leaks and invalid access at probe error pathDeinitialize at reverse order when probe fails.When init_sw_vars fails, rtl_deinit_core should not be called, speciallynow that it destroys the rtl_wq workqueue.And call rtl_pci_deinit and deinit_sw_vars, otherwise, memory will beleaked.Remove pci_set_drvdata call as it will already be cleaned up by the coredriver code and could lead to memory leaks too. cf. commit 8d450935ae7f("wireless: rtlwifi: remove unnecessary pci_set_drvdata()") andcommit 3d86b93064c7 ("rtlwifi: Fix PCI probe error path orphaned memory").

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtc: pcf85063: fix potential OOB write in PCF85063 NVMEM readThe nvmem interface supports variable buffer sizes, while the regmapinterface operates with fixed-size storage. If an nvmem client uses abuffer size less than 4 bytes, regmap_read will write out of boundsas it expects the buffer to point at an unsigned int.Fix this by using an intermediary unsigned int to hold the value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: prevent adding a device which is already a team device lowerPrevent adding a device which is already a team device lower,e.g. adding veth0 if vlan1 was already added and veth0 is a lower ofvlan1.This is not useful in practice and can lead to recursive locking:$ ip link add veth0 type veth peer name veth1$ ip link set veth0 up$ ip link set veth1 up$ ip link add link veth0 name veth0.1 type vlan protocol 802.1Q id 1$ ip link add team0 type team$ ip link set veth0.1 down$ ip link set veth0.1 master team0team0: Port device veth0.1 added$ ip link set veth0 down$ ip link set veth0 master team0============================================WARNING: possible recursive locking detected6.13.0-rc2-virtme-00441-ga14a429069bb #46 Not tainted--------------------------------------------ip/7684 is trying to acquire lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)but task is already holding lock:ffff888016848e00 (team->team_lock_key){+.+.}-{4:4}, at: team_add_slave (drivers/net/team/team_core.c:1147 drivers/net/team/team_core.c:1977)other info that might help us debug this:Possible unsafe locking scenario:CPU0----lock(team->team_lock_key);lock(team->team_lock_key);*** DEADLOCK ***May be due to missing lock nesting notation2 locks held by ip/7684:stack backtrace:CPU: 3 UID: 0 PID: 7684 Comm: ip Not tainted 6.13.0-rc2-virtme-00441-ga14a429069bb #46Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014Call Trace:dump_stack_lvl (lib/dump_stack.c:122)print_deadlock_bug.cold (kernel/locking/lockdep.c:3040)__lock_acquire (kernel/locking/lockdep.c:3893 kernel/locking/lockdep.c:5226)? netlink_broadcast_filtered (net/netlink/af_netlink.c:1548)lock_acquire.part.0 (kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? trace_lock_acquire (./include/trace/events/lock.h:24 (discriminator 2))? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? lock_acquire (kernel/locking/lockdep.c:5822)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)__mutex_lock (kernel/locking/mutex.c:587 kernel/locking/mutex.c:735)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)? fib_sync_up (net/ipv4/fib_semantics.c:2167)? team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)team_device_event (drivers/net/team/team_core.c:2928 drivers/net/team/team_core.c:2951 drivers/net/team/team_core.c:2973)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)__dev_notify_flags (net/core/dev.c:8993)? __dev_change_flags (net/core/dev.c:8975)dev_change_flags (net/core/dev.c:9027)vlan_device_event (net/8021q/vlan.c:85 net/8021q/vlan.c:470)? br_device_event (net/bridge/br.c:143)notifier_call_chain (kernel/notifier.c:85)call_netdevice_notifiers_info (net/core/dev.c:1996)dev_open (net/core/dev.c:1519 net/core/dev.c:1505)team_add_slave (drivers/net/team/team_core.c:1219 drivers/net/team/team_core.c:1977)? __pfx_team_add_slave (drivers/net/team/team_core.c:1972)do_set_master (net/core/rtnetlink.c:2917)do_setlink.isra.0 (net/core/rtnetlink.c:3117)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtlwifi: remove unused check_buddy_privCommit 2461c7d60f9f ("rtlwifi: Update header file") introduced a globallist of private data structures.Later on, commit 26634c4b1868 ("rtlwifi Modify existing bits to matchvendor version 2013.02.07") started adding the private data to that list atprobe time and added a hook, check_buddy_priv to find the private data froma similar device.However, that function was never used.Besides, though there is a lock for that list, it is never used. And whenthe probe fails, the private data is never removed from the list. Thiswould cause a second probe to access freed memory.Remove the unused hook, structures and members, which will prevent thepotential race condition on the list and its corruption during a secondprobe when probe fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix crash during unbind if gpio unit is in useWe used the wrong device for the device managed functions. We used theusb device, when we should be using the interface device.If we unbind the driver from the usb interface, the cleanup functionsare never called. In our case, the IRQ is never disabled.If an IRQ is triggered, it will try to access memory sections that arealready free, causing an OOPS.We cannot use the function devm_request_threaded_irq here. The devm_*clean functions may be called after the main structure is released byuvc_delete.Luckily this bug has small impact, as it is only affected by deviceswith gpio units and the user has to unbind the device, a disconnect willnot trigger this error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58089 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double accounting race when btrfs_run_delalloc_range() failed[BUG]When running btrfs with block size (4K) smaller than page size (64K,aarch64), there is a very high chance to crash the kernel atgeneric/750, with the following messages:(before the call traces, there are 3 extra debug messages added) BTRFS warning (device dm-3): read-write for sector size 4096 with page size 65536 is experimental BTRFS info (device dm-3): checking UUID tree hrtimer: interrupt took 5451385 ns BTRFS error (device dm-3): cow_file_range failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): run_delalloc_nocow failed, root=4957 inode=257 start=1605632 len=69632: -28 BTRFS error (device dm-3): failed to run delalloc range, root=4957 ino=257 folio=1572864 submit_bitmap=8-15 start=1605632 len=69632: -28 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 3020984 at ordered-data.c:360 can_finish_ordered_extent+0x370/0x3b8 [btrfs] CPU: 2 UID: 0 PID: 3020984 Comm: kworker/u24:1 Tainted: G OE 6.13.0-rc1-custom+ #89 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs] pc : can_finish_ordered_extent+0x370/0x3b8 [btrfs] lr : can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] Call trace: can_finish_ordered_extent+0x370/0x3b8 [btrfs] (P) can_finish_ordered_extent+0x1ec/0x3b8 [btrfs] (L) btrfs_mark_ordered_io_finished+0x130/0x2b8 [btrfs] extent_writepage+0x10c/0x3b8 [btrfs] extent_write_cache_pages+0x21c/0x4e8 [btrfs] btrfs_writepages+0x94/0x160 [btrfs] do_writepages+0x74/0x190 filemap_fdatawrite_wbc+0x74/0xa0 start_delalloc_inodes+0x17c/0x3b0 [btrfs] btrfs_start_delalloc_roots+0x17c/0x288 [btrfs] shrink_delalloc+0x11c/0x280 [btrfs] flush_space+0x288/0x328 [btrfs] btrfs_async_reclaim_data_space+0x180/0x228 [btrfs] process_one_work+0x228/0x680 worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1605632 OE len=16384 to_dec=16384 left=0 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1622016 OE len=12288 to_dec=12288 left=0 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 BTRFS critical (device dm-3): bad ordered extent accounting, root=4957 ino=257 OE offset=1634304 OE len=8192 to_dec=4096 left=0 CPU: 1 UID: 0 PID: 3286940 Comm: kworker/u24:3 Tainted: G W OE 6.13.0-rc1-custom+ #89 Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022 Workqueue: btrfs_work_helper [btrfs] (btrfs-endio-write) pstate: 404000c5 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : process_one_work+0x110/0x680 lr : worker_thread+0x1bc/0x360 Call trace: process_one_work+0x110/0x680 (P) worker_thread+0x1bc/0x360 (L) worker_thread+0x1bc/0x360 kthread+0x100/0x118 ret_from_fork+0x10/0x20 Code: f84086a1 f9000fe1 53041c21 b9003361 (f9400661) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception SMP: stopping secondary CPUs SMP: failed to stop secondary CPUs 2-3 Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x275bb9540000 from 0xffff800080000000 PHYS_OFFSET: 0xffff8fbba0000000 CPU features: 0x100,00000070,00801250,8201720b[CAUSE]The above warning is triggered immediately after the delalloc rangefailure, this happens in the following sequence:- Range [1568K, 1636K) is dirty 1536K 1568K 1600K 1636K 1664K | |/////////|////////| | Where 1536K, 1600K and 1664K are page boundaries (64K page size)- Enter extent_writepage() for page 1536K- Enter run_delalloc_nocow() with locke---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/core: Prevent rescheduling when interrupts are disabledDavid reported a warning observed while loop testing kexec jump: Interrupts enabled after irqrouter_resume+0x0/0x50 WARNING: CPU: 0 PID: 560 at drivers/base/syscore.c:103 syscore_resume+0x18a/0x220 kernel_kexec+0xf6/0x180 __do_sys_reboot+0x206/0x250 do_syscall_64+0x95/0x180The corresponding interrupt flag trace: hardirqs last enabled at (15573): [] __up_console_sem+0x7e/0x90 hardirqs last disabled at (15580): [] __up_console_sem+0x63/0x90That means __up_console_sem() was invoked with interrupts enabled. Furtherinstrumentation revealed that in the interrupt disabled section of kexecjump one of the syscore_suspend() callbacks woke up a task, which set theNEED_RESCHED flag. A later callback in the resume path invokedcond_resched() which in turn led to the invocation of the scheduler: __cond_resched+0x21/0x60 down_timeout+0x18/0x60 acpi_os_wait_semaphore+0x4c/0x80 acpi_ut_acquire_mutex+0x3d/0x100 acpi_ns_get_node+0x27/0x60 acpi_ns_evaluate+0x1cb/0x2d0 acpi_rs_set_srs_method_data+0x156/0x190 acpi_pci_link_set+0x11c/0x290 irqrouter_resume+0x54/0x60 syscore_resume+0x6a/0x200 kernel_kexec+0x145/0x1c0 __do_sys_reboot+0xeb/0x240 do_syscall_64+0x95/0x180This is a long standing problem, which probably got more visible withthe recent printk changes. Something does a task wakeup and thescheduler sets the NEED_RESCHED flag. cond_resched() sees it set andinvokes schedule() from a completely bogus context. The schedulerenables interrupts after context switching, which causes the abovewarning at the end.Quite some of the code paths in syscore_suspend()/resume() can result intriggering a wakeup with the exactly same consequences. They might nothave done so yet, but as they share a lot of code with normal operationsit's just a question of time.The problem only affects the PREEMPT_NONE and PREEMPT_VOLUNTARY schedulingmodels. Full preemption is not affected as cond_resched() is disabled andthe preemption check preemptible() takes the interrupt disabled flag intoaccount.Cure the problem by adding a corresponding check into cond_resched().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix link state exit during switch upstream function removalBefore 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal toavoid use-after-free"), we would free the ASPM link only after the lastfunction on the bus pertaining to the given link was removed.That was too late. If function 0 is removed before sibling function,link->downstream would point to free'd memory after.After above change, we freed the ASPM parent link state upon any functionremoval on the bus pertaining to a given link.That is too early. If the link is to a PCIe switch with MFD on the upstreamport, then removing functions other than 0 first would free a link whichstill remains parent_link to the remaining downstream ports.The resulting GPFs are especially frequent during hot-unplug, becausepciehp removes devices on the link bus in reverse order.On that switch, function 0 is the virtual P2P bridge to the internal bus.Free exactly when function 0 is removed -- before the parent link isobsolete, but after all subordinate links are gone.[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix RCU stall while reaping monitor destination ringWhile processing the monitor destination ring, MSDUs are reaped from thelink descriptor based on the corresponding buf_id.However, sometimes the driver cannot obtain a valid buffer correspondingto the buf_id received from the hardware. This causes an infinite loopin the destination processing, resulting in a kernel crash.kernel log:ath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedath11k_pci 0000:58:00.0: data msdu_pop: invalid buf_id 309ath11k_pci 0000:58:00.0: data dp_rx_monitor_link_desc_return failedFix this by skipping the problematic buf_id and reaping the next entry,replacing the break with the next MSDU processing.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: track changes_pkt_data property for global functionsWhen processing calls to certain helpers, verifier invalidates allpacket pointers in a current state. For example, consider thefollowing program: __attribute__((__noinline__)) long skb_pull_data(struct __sk_buff *sk, __u32 len) { return bpf_skb_pull_data(sk, len); } SEC("tc") int test_invalidate_checks(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP; skb_pull_data(sk, 0); *p = 42; return TCX_PASS; }After a call to bpf_skb_pull_data() the pointer 'p' can't be usedsafely. See function filter.c:bpf_helper_changes_pkt_data() for a listof such helpers.At the moment verifier invalidates packet pointers when processinghelper function calls, and does not traverse global sub-programs whenprocessing calls to global sub-programs. This means that calls tohelpers done from global sub-programs do not invalidate pointers inthe caller state. E.g. the program above is unsafe, but is notrejected by verifier.This commit fixes the omission by computing fieldbpf_subprog_info->changes_pkt_data for each sub-program before mainverification pass.changes_pkt_data should be set if:- subprogram calls helper for which bpf_helper_changes_pkt_data returns true;- subprogram calls a global function, for which bpf_subprog_info->changes_pkt_data should be set.The verifier.c:check_cfg() pass is modified to compute thisinformation. The commit relies on depth first instruction traversaldone by check_cfg() and absence of recursive function calls:- check_cfg() would eventually visit every call to subprogram S in a state when S is fully explored;- when S is fully explored: - every direct helper call within S is explored (and thus changes_pkt_data is set if needed); - every call to subprogram S1 called by S was visited with S1 fully explored (and thus S inherits changes_pkt_data from S1).The downside of such approach is that dead code elimination is nottaken into account: if a helper call inside global function is deadbecause of current configuration, verifier would conservatively assumethat the call occurs for the purpose of the changes_pkt_datacomputation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58100 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: check changes_pkt_data property for extension programsWhen processing calls to global sub-programs, verifier decides whetherto invalidate all packet pointers in current state depending on thechanges_pkt_data property of the global sub-program.Because of this, an extension program replacing a global sub-programmust be compatible with changes_pkt_data property of the sub-programbeing replaced.This commit:- adds changes_pkt_data flag to struct bpf_prog_aux: - this flag is set in check_cfg() for main sub-program; - in jit_subprogs() for other sub-programs;- modifies bpf_check_attach_btf_id() to check changes_pkt_data flag;- moves call to check_attach_btf_id() after the call to check_cfg(), because it needs changes_pkt_data flag to be set: bpf_check: ... ... - check_attach_btf_id resolve_pseudo_ldimm64 resolve_pseudo_ldimm64 --> bpf_prog_is_offloaded bpf_prog_is_offloaded check_cfg check_cfg + check_attach_btf_id ... ...The following fields are set by check_attach_btf_id():- env->ops- prog->aux->attach_btf_trace- prog->aux->attach_func_name- prog->aux->attach_func_proto- prog->aux->dst_trampoline- prog->aux->mod- prog->aux->saved_dst_attach_type- prog->aux->saved_dst_prog_type- prog->expected_attach_typeNeither of these fields are used by resolve_pseudo_ldimm64() orbpf_prog_offload_verifier_prep() (for netronome and netdevsimdrivers), so the reordering is safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: consider that tail calls invalidate packet pointersTail-called programs could execute any of the helpers that invalidatepacket pointers. Hence, conservatively assume that each tail callinvalidates packet pointers.Making the change in bpf_helper_changes_pkt_data() automatically makesuse of check_cfg() logic that computes 'changes_pkt_data' effect forglobal sub-programs, such that the following program could berejected: int tail_call(struct __sk_buff *sk) { bpf_tail_call_static(sk, &jmp_table, 0); return 0; } SEC("tc") int not_safe(struct __sk_buff *sk) { int *p = (void *)(long)sk->data; ... make p valid ... tail_call(sk); *p = 42; /* this is unsafe */ ... }The tc_bpf2bpf.c:subprog_tc() needs change: mark it as a function thatcan invalidate packet pointers. Otherwise, it can't be freplaced withtailcall_freplace.c:entry_freplace() that does a tail call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-10911 Severity: Moderate CVSS3 score: 5.5

Description: A use-after-free vulnerability was found in libxslt while parsing xsl nodes that may lead to the dereference of expired pointers and application crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxslt1 > 0-0 (version in image is 1.1.34-150400.3.6.1).

CVE-2025-15281 Severity: Moderate CVSS3 score: 5.5

Description: Calling wordexp with WRDE_REUSE in conjunction with WRDE_APPEND in the GNU C Library version 2.0 to version 2.42 may cause the interface to return uninitialized memory in the we_wordv member, which on subsequent calls to wordfree may abort the process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc > 0-0 (version in image is 2.31-150300.95.1).

CVE-2025-21635 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The per-netns structure can be obtained from the table->data usingcontainer_of(), then the 'net' one can be retrieved from the listensocket (if available).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21636 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: plpmtud_probe_interval: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.probe_interval' isused.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21637 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: udp_port: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21638 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: auth_enable: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, but that wouldincrease the size of this fix, while 'sctp.ctl_sock' still needs to beretrieved from 'net' structure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21639 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: rto_min/max: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.rto_min/max' is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21640 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: sysctl: cookie_hmac_alg: avoid using current->nsproxyAs mentioned in a previous commit of this series, using the 'net'structure via 'current' is not recommended for different reasons:- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).The 'net' structure can be obtained from the table->data usingcontainer_of().Note that table->data could also be used directly, as this is the onlymember needed from the 'net' structure, but that would increase the sizeof this fix, to use '*data' everywhere 'net->sctp.sctp_hmac_alg' isused.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21646 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix the maximum cell name lengthThe kafs filesystem limits the maximum length of a cell to 256 bytes, but aproblem occurs if someone actually does that: kafs tries to create adirectory under /proc/net/afs/ with the name of the cell, but that failswith a warning: WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:405because procfs limits the maximum filename length to 255.However, the DNS limits the maximum lookup length and, by extension, themaximum cell name, to 255 less two (length count and trailing NUL).Fix this by limiting the maximum acceptable cellname length to 253. Thisalso allows us to be sure we can create the "/afs/./" mountpoint too.Further, split the YFS VL record cell name maximum to be the 256 allowed bythe protocol and ignore the record retrieved by YFSVL.GetCellName if itexceeds 253.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21649 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is sent on HIP08 devicesCurrently, HIP08 devices does not register the ptp devices, so thehdev->ptp is NULL. But the tx process would still try to set hardware timestamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.[ 128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018...[ 128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge][ 128.292938] sp : ffff800059b93140[ 128.297200] x29: ffff800059b93140 x28: 0000000000003280[ 128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080[ 128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001[ 128.315969] x23: 0000000000000000 x22: 0000000000000194[ 128.322219] x21: ffff0cd94f986000 x20: 0000000000000000[ 128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000[ 128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24[ 128.340934] x15: 0000ffffd530a518 x14: 0000000000000000[ 128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368[ 128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02[ 128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0[ 128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000[ 128.372040] x5 : 0000000000000000 x4 : 000000000000ffff[ 128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294[ 128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080[ 128.390626] Call trace:[ 128.393964] hclge_ptp_set_tx_info+0x2c/0x140 [hclge][ 128.399893] hns3_nic_net_xmit+0x39c/0x4c4 [hns3][ 128.405468] xmit_one.constprop.0+0xc4/0x200[ 128.410600] dev_hard_start_xmit+0x54/0xf0[ 128.415556] sch_direct_xmit+0xe8/0x634[ 128.420246] __dev_queue_xmit+0x224/0xc70[ 128.425101] dev_queue_xmit+0x1c/0x40[ 128.429608] ovs_vport_send+0xac/0x1a0 [openvswitch][ 128.435409] do_output+0x60/0x17c [openvswitch][ 128.440770] do_execute_actions+0x898/0x8c4 [openvswitch][ 128.446993] ovs_execute_actions+0x64/0xf0 [openvswitch][ 128.453129] ovs_dp_process_packet+0xa0/0x224 [openvswitch][ 128.459530] ovs_vport_receive+0x7c/0xfc [openvswitch][ 128.465497] internal_dev_xmit+0x34/0xb0 [openvswitch][ 128.471460] xmit_one.constprop.0+0xc4/0x200[ 128.476561] dev_hard_start_xmit+0x54/0xf0[ 128.481489] __dev_queue_xmit+0x968/0xc70[ 128.486330] dev_queue_xmit+0x1c/0x40[ 128.490856] ip_finish_output2+0x250/0x570[ 128.495810] __ip_finish_output+0x170/0x1e0[ 128.500832] ip_finish_output+0x3c/0xf0[ 128.505504] ip_output+0xbc/0x160[ 128.509654] ip_send_skb+0x58/0xd4[ 128.513892] udp_send_skb+0x12c/0x354[ 128.518387] udp_sendmsg+0x7a8/0x9c0[ 128.522793] inet_sendmsg+0x4c/0x8c[ 128.527116] __sock_sendmsg+0x48/0x80[ 128.531609] __sys_sendto+0x124/0x164[ 128.536099] __arm64_sys_sendto+0x30/0x5c[ 128.540935] invoke_syscall+0x50/0x130[ 128.545508] el0_svc_common.constprop.0+0x10c/0x124[ 128.551205] do_el0_svc+0x34/0xdc[ 128.555347] el0_svc+0x20/0x30[ 128.559227] el0_sync_handler+0xb8/0xc0[ 128.563883] el0_sync+0x160/0x180

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21658 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid NULL pointer dereference if no valid extent tree[BUG]Syzbot reported a crash with the following call trace: BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOT_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:find_first_extent_item+0x26/0x1f0 [btrfs] Call Trace: scrub_find_fill_first_stripe+0x13d/0x3b0 [btrfs] scrub_simple_mirror+0x175/0x260 [btrfs] scrub_stripe+0x5d4/0x6c0 [btrfs] scrub_chunk+0xbb/0x170 [btrfs] scrub_enumerate_chunks+0x2f4/0x5f0 [btrfs] btrfs_scrub_dev+0x240/0x600 [btrfs] btrfs_ioctl+0x1dc8/0x2fa0 [btrfs] ? do_sys_openat2+0xa5/0xf0 __x64_sys_ioctl+0x97/0xc0 do_syscall_64+0x4f/0x120 entry_SYSCALL_64_after_hwframe+0x76/0x7e [CAUSE]The reproducer is using a corrupted image where extent tree root iscorrupted, thus forcing to use "rescue=all,ro" mount option to mount theimage.Then it triggered a scrub, but since scrub relies on extent tree to findwhere the data/metadata extents are, scrub_find_fill_first_stripe()relies on an non-empty extent root.But unfortunately scrub_find_fill_first_stripe() doesn't really expectan NULL pointer for extent root, it use extent_root to grab fs_info andtriggered a NULL pointer dereference.[FIX]Add an extra check for a valid extent root at the beginning ofscrub_find_fill_first_stripe().The new error path is introduced by 42437a6386ff ("btrfs: introducemount option rescue=ignorebadroots"), but that's pretty old, and latercommit b979547513ff ("btrfs: scrub: introduce helper to find and fillsector info for a scrub_stripe") changed how we do scrub.So for kernels older than 6.6, the fix will need manual backport.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21665 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:filemap: avoid truncating 64-bit offset to 32 bitsOn 32-bit kernels, folio_seek_hole_data() was inadvertently truncating a64-bit value to 32 bits, leading to a possible infinite loop when writingto an xfs filesystem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21666 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: prevent null-ptr-deref in vsock_*[has_data|has_space]Recent reports have shown how we sometimes call vsock_*_has_data()when a vsock socket has been de-assigned from a transport (see attachedlinks), but we shouldn't.Previous commits should have solved the real problems, but we may havemore in the future, so to avoid null-ptr-deref, we can return 0(no space, no data available) but with a warning.This way the code should continue to run in a nearly consistent stateand have a warning that allows us to debug future problems.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clear port select structure when fail to createClear the port select structure on error so no stale values left afterdefiners are destroyed. That's because the mlx5_lag_destroy_definers()always try to destroy all lag definers in the tt_map, so in the flowbelow lag definers get double-destroyed and cause kernel crash: mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 1 mlx5_lag_destroy_definers() <- definers[tt=0] gets destroyed mlx5_lag_port_sel_create() mlx5_lag_create_definers() mlx5_lag_create_definer() <- Failed on tt 0 mlx5_lag_destroy_definers() <- definers[tt=0] gets double-destroyed Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 64k pages, 48-bit VAs, pgdp=0000000112ce2e00 [0000000000000008] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP Modules linked in: iptable_raw bonding ip_gre ip6_gre gre ip6_tunnel tunnel6 geneve ip6_udp_tunnel udp_tunnel ipip tunnel4 ip_tunnel rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) mlx5_fwctl(OE) fwctl(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlxfw(OE) memtrack(OE) mlx_compat(OE) openvswitch nsh nf_conncount psample xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc netconsole overlay efi_pstore sch_fq_codel zram ip_tables crct10dif_ce qemu_fw_cfg fuse ipv6 crc_ccitt [last unloaded: mlx_compat(OE)] CPU: 3 UID: 0 PID: 217 Comm: kworker/u53:2 Tainted: G OE 6.11.0+ #2 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Workqueue: mlx5_lag mlx5_do_bond_work [mlx5_core] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] lr : mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] sp : ffff800085fafb00 x29: ffff800085fafb00 x28: ffff0000da0c8000 x27: 0000000000000000 x26: ffff0000da0c8000 x25: ffff0000da0c8000 x24: ffff0000da0c8000 x23: ffff0000c31f81a0 x22: 0400000000000000 x21: ffff0000da0c8000 x20: 0000000000000000 x19: 0000000000000001 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffff8b0c9350 x14: 0000000000000000 x13: ffff800081390d18 x12: ffff800081dc3cc0 x11: 0000000000000001 x10: 0000000000000b10 x9 : ffff80007ab7304c x8 : ffff0000d00711f0 x7 : 0000000000000004 x6 : 0000000000000190 x5 : ffff00027edb3010 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff0000d39b8000 x1 : ffff0000d39b8000 x0 : 0400000000000000 Call trace: mlx5_del_flow_rules+0x24/0x2c0 [mlx5_core] mlx5_lag_destroy_definer+0x54/0x100 [mlx5_core] mlx5_lag_destroy_definers+0xa0/0x108 [mlx5_core] mlx5_lag_port_sel_create+0x2d4/0x6f8 [mlx5_core] mlx5_activate_lag+0x60c/0x6f8 [mlx5_core] mlx5_do_bond_work+0x284/0x5c8 [mlx5_core] process_one_work+0x170/0x3e0 worker_thread+0x2d8/0x3e0 kthread+0x11c/0x128 ret_from_fork+0x10/0x20 Code: a9025bf5 aa0003f6 a90363f7 f90023f9 (f9400400) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21678 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gtp: Destroy device along with udp socket's netns dismantle.gtp_newlink() links the device to a list in dev_net(dev) instead ofsrc_net, where a udp tunnel socket is created.Even when src_net is removed, the device stays alive on dev_net(dev).Then, removing src_net triggers the splat below. [0]In this example, gtp0 is created in ns2, and the udp socket is createdin ns1. ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1Let's link the device to the socket's netns instead.Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to removeall gtp devices in the netns.[0]:ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347) netlink_sendmsg (net/netlink/af_netlink.c:1891) ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) ___sys_sendmsg (net/socket.c:2639) __sys_sendmsg (net/socket.c:2669) do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)WARNING: CPU: 1 PID: 60 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)Modules linked in:CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: netns cleanup_netRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89RSP: 0018:ff11000009a07b60 EFLAGS: 00010286RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3cRBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395aeR10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __warn (kernel/panic.c:748) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:285) ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194) ? ref_tracker_dir_exit (lib/ref_tracker.c:179) ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467) cleanup_net (net/core/net_namespace.c:664 (discriminator 3)) process_one_work (kernel/workqueue.c:3229) worker_thread (kernel/workqueue.c:3304 kernel/workqueue.c:3391---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: serial: quatech2: fix null-ptr-deref in qt2_process_read_urb()This patch addresses a null-ptr-deref in qt2_process_read_urb() due toan incorrect bounds check in the following: if (newport > serial->num_ports) { dev_err(&port->dev, "%s - port change to invalid port: %i\n", __func__, newport); break; }The condition doesn't account for the valid range of the serial->portbuffer, which is from 0 to serial->num_ports - 1. When newport is equalto serial->num_ports, the assignment of "port" in thefollowing code is out-of-bounds and NULL: serial_priv->current_port = newport; port = serial->port[serial_priv->current_port];The fix checks if newport is greater than or equal to serial->num_portsindicating it is out-of-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21696 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: clear uffd-wp PTE/PMD state on mremap()When mremap()ing a memory region previously registered with userfaultfd aswrite-protected but without UFFD_FEATURE_EVENT_REMAP, an inconsistency inflag clearing leads to a mismatch between the vma flags (which haveuffd-wp cleared) and the pte/pmd flags (which do not have uffd-wpcleared). This mismatch causes a subsequent mprotect(PROT_WRITE) totrigger a warning in page_table_check_pte_flags() due to setting the pteto writable while uffd-wp is still set.Fix this by always explicitly clearing the uffd-wp pte/pmd flags on anysuch mremap() so that the values are consistent with the existing clearingof VM_UFFD_WP. Be careful to clear the logical flag regardless of itsphysical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE,huge PMD and hugetlb paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21707 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: consolidate suboption statusMPTCP maintains the received sub-options status is the bitmask carryingthe received suboptions and in several bitfields carrying per suboptionadditional info.Zeroing the bitmask before parsing is not enough to ensure a consistentstatus, and the MPTCP code has to additionally clear some bitfileddepending on the actually parsed suboption.The above schema is fragile, and syzbot managed to trigger a path wherea relevant bitfield is not cleared/initialized: BUG: KMSAN: uninit-value in __mptcp_expand_seq net/mptcp/options.c:1030 [inline] BUG: KMSAN: uninit-value in mptcp_expand_seq net/mptcp/protocol.h:864 [inline] BUG: KMSAN: uninit-value in ack_update_msk net/mptcp/options.c:1060 [inline] BUG: KMSAN: uninit-value in mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 __mptcp_expand_seq net/mptcp/options.c:1030 [inline] mptcp_expand_seq net/mptcp/protocol.h:864 [inline] ack_update_msk net/mptcp/options.c:1060 [inline] mptcp_incoming_options+0x2036/0x3d30 net/mptcp/options.c:1209 tcp_data_queue+0xb4/0x7be0 net/ipv4/tcp_input.c:5233 tcp_rcv_established+0x1061/0x2510 net/ipv4/tcp_input.c:6264 tcp_v4_do_rcv+0x7f3/0x11a0 net/ipv4/tcp_ipv4.c:1916 tcp_v4_rcv+0x51df/0x5750 net/ipv4/tcp_ipv4.c:2351 ip_protocol_deliver_rcu+0x2a3/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233 NF_HOOK include/linux/netfilter.h:314 [inline] ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254 dst_input include/net/dst.h:460 [inline] ip_rcv_finish+0x4a2/0x520 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] ip_rcv+0xcd/0x380 net/ipv4/ip_input.c:567 __netif_receive_skb_one_core net/core/dev.c:5704 [inline] __netif_receive_skb+0x319/0xa00 net/core/dev.c:5817 process_backlog+0x4ad/0xa50 net/core/dev.c:6149 __napi_poll+0xe7/0x980 net/core/dev.c:6902 napi_poll net/core/dev.c:6971 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:7093 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4493 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0x187c/0x1b70 net/ipv4/ip_output.c:236 __ip_finish_output+0x287/0x810 ip_finish_output+0x4b/0x600 net/ipv4/ip_output.c:324 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip_output+0x15f/0x3f0 net/ipv4/ip_output.c:434 dst_output include/net/dst.h:450 [inline] ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x1f2a/0x20d0 net/ipv4/ip_output.c:536 ip_queue_xmit+0x60/0x80 net/ipv4/ip_output.c:550 __tcp_transmit_skb+0x3cea/0x4900 net/ipv4/tcp_output.c:1468 tcp_transmit_skb net/ipv4/tcp_output.c:1486 [inline] tcp_write_xmit+0x3b90/0x9070 net/ipv4/tcp_output.c:2829 __tcp_push_pending_frames+0xc4/0x380 net/ipv4/tcp_output.c:3012 tcp_send_fin+0x9f6/0xf50 net/ipv4/tcp_output.c:3618 __tcp_close+0x140c/0x1550 net/ipv4/tcp.c:3130 __mptcp_close_ssk+0x74e/0x16f0 net/mptcp/protocol.c:2496 mptcp_close_ssk+0x26b/0x2c0 net/mptcp/protocol.c:2550 mptcp_pm_nl_rm_addr_or_subflow+0x635/0xd10 net/mptcp/pm_netlink.c:889 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:924 [inline] mptcp_pm_flush_addrs_and_subflows net/mptcp/pm_netlink.c:1688 [inline] mptcp_nl_flush_addrs_list net/mptcp/pm_netlink.c:1709 [inline] mptcp_pm_nl_flush_addrs_doit+0xe10/0x1630 net/mptcp/pm_netlink.c:1750 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21708 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: rtl8150: enable basic endpoint checkingSyzkaller reports [1] encountering a common issue of utilizing a wrongusb endpoint type during URB submitting stage. This, in turn, triggersa warning shown below.For now, enable simple endpoint checking (specifically, bulk andinterrupt eps, testing control one is not essential) to mitigatethe issue with a view to do other related cosmetic changes later,if they are necessary.[1] Syzkaller report:usb 1-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>Modules linked in:CPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024RIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Code: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>RSP: 0018:ffffc9000441f740 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9RDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001RBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001R13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7cFS: 00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733 __dev_open+0x2d4/0x4e0 net/core/dev.c:1474 __dev_change_flags+0x561/0x720 net/core/dev.c:8838 dev_change_flags+0x8f/0x160 net/core/dev.c:8910 devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177 inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003 sock_do_ioctl+0x116/0x280 net/socket.c:1222 sock_ioctl+0x22e/0x6c0 net/socket.c:1341 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fc04ef73d49...This change has not been tested on real hardware.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21712 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/md-bitmap: Synchronize bitmap_get_stats() with bitmap lifetimeAfter commit ec6bb299c7c3 ("md/md-bitmap: add 'sync_size' into structmd_bitmap_stats"), following panic is reported:Oops: general protection fault, probably for non-canonical addressRIP: 0010:bitmap_get_stats+0x2b/0xa0Call Trace: md_seq_show+0x2d2/0x5b0 seq_read_iter+0x2b9/0x470 seq_read+0x12f/0x180 proc_reg_read+0x57/0xb0 vfs_read+0xf6/0x380 ksys_read+0x6c/0xf0 do_syscall_64+0x82/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eRoot cause is that bitmap_get_stats() can be called at anytime if mddevis still there, even if bitmap is destroyed, or not fully initialized.Deferenceing bitmap in this case can crash the kernel. Meanwhile, theabove commit start to deferencing bitmap->storage, make the problemeasier to trigger.Fix the problem by protecting bitmap_get_stats() with bitmap_info.mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21715 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: davicom: fix UAF in dm9000_drv_removedm is netdev private data and it cannot beused after free_netdev() call. Using dm after free_netdev()can cause UAF bug. Fix it by moving free_netdev() at the end of thefunction.This is similar to the issue fixed in commitad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").This bug is detected by our static analysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21719 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmr: do not call mr_mfc_uses_dev() for unres entriessyzbot found that calling mr_mfc_uses_dev() for unres entrieswould crash [1], because c->mfc_un.res.minvif / c->mfc_un.res.maxvifalias to "struct sk_buff_head unresolved", which contain two pointers.This code never worked, lets remove it.[1]Unable to handle kernel paging request at virtual address ffff5fff2d536613KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f]Modules linked in:CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] pc : mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 lr : mr_mfc_uses_dev net/ipv4/ipmr_base.c:289 [inline] lr : mr_table_dump+0x694/0x8b0 net/ipv4/ipmr_base.c:334Call trace: mr_mfc_uses_dev net/ipv4/ipmr_base.c:290 [inline] (P) mr_table_dump+0x5a4/0x8b0 net/ipv4/ipmr_base.c:334 (P) mr_rtm_dumproute+0x254/0x454 net/ipv4/ipmr_base.c:382 ipmr_rtm_dumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnl_dump_all+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnl_dumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlink_dump+0x4f0/0xbc0 net/netlink/af_netlink.c:2317 netlink_recvmsg+0x56c/0xe64 net/netlink/af_netlink.c:1973 sock_recvmsg_nosec net/socket.c:1033 [inline] sock_recvmsg net/socket.c:1055 [inline] sock_read_iter+0x2d8/0x40c net/socket.c:1125 new_sync_read fs/read_write.c:484 [inline] vfs_read+0x740/0x970 fs/read_write.c:565 ksys_read+0x15c/0x26c fs/read_write.c:708

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21727 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:padata: fix UAF in padata_reorderA bug was found when run ltp test:BUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+Workqueue: pdecrypt_parallel padata_parallel_workerCall Trace:dump_stack_lvl+0x32/0x50print_address_description.constprop.0+0x6b/0x3d0print_report+0xdd/0x2c0kasan_report+0xa5/0xd0padata_find_next+0x29/0x1a0padata_reorder+0x131/0x220padata_parallel_worker+0x3d/0xc0process_one_work+0x2ec/0x5a0If 'mdelay(10)' is added before calling 'padata_find_next' in the'padata_reorder' function, this issue could be reproduced easily withltp test (pcrypt_aead01).This can be explained as bellow:pcrypt_aead_encrypt...padata_do_parallelrefcount_inc(&pd->refcnt); // add refcnt...padata_do_serialpadata_reorder // pdwhile (1) {padata_find_next(pd, true); // using pdqueue_work_on...padata_serial_worker crypto_del_algpadata_put_pd_cnt // sub refcnt padata_free_shell padata_put_pd(ps->pd); // pd is freed// loop again, but pd is freed// call padata_find_next, UAF}In the padata_reorder function, when it loops in 'while', if the alg isdeleted, the refcnt may be decreased to 0 before entering'padata_find_next', which leads to UAF.As mentioned in [1], do_serial is supposed to be called with BHs disabledand always happen under RCU protection, to address this issue, addsynchronize_rcu() in 'padata_free_shell' wait for all _do_serial callsto finish.[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Send signals asynchronously if !preemptibleBPF programs can execute in all kinds of contexts and when a programrunning in a non-preemptible context uses the bpf_send_signal() kfunc,it will cause issues because this kfunc can sleep.Change `irqs_disabled()` to `!preemptible()`.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21731 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: don't allow reconnect after disconnectFollowing process can cause nbd_config UAF:1) grab nbd_config temporarily;2) nbd_genl_disconnect() flush all recv_work() and release theinitial reference: nbd_genl_disconnect nbd_disconnect_and_put nbd_disconnect flush_workqueue(nbd->recv_workq) if (test_and_clear_bit(NBD_RT_HAS_CONFIG_REF, ...)) nbd_config_put -> due to step 1), reference is still not zero3) nbd_genl_reconfigure() queue recv_work() again; nbd_genl_reconfigure config = nbd_get_config_unlocked(nbd) if (!config) -> succeed if (!test_bit(NBD_RT_BOUND, ...)) -> succeed nbd_reconnect_socket queue_work(nbd->recv_workq, &args->work)4) step 1) release the reference;5) Finially, recv_work() will trigger UAF: recv_work nbd_config_put(nbd) -> nbd_config is freed atomic_dec(&config->recv_threads) -> UAFFix the problem by clearing NBD_RT_BOUND in nbd_genl_disconnect(), sothat nbd_genl_reconfigure() will fail.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix copy buffer page sizeFor non-registered buffer, fastrpc driver copies the buffer andpass it to the remote subsystem. There is a problem with currentimplementation of page size calculation which is not consideringthe offset in the calculation. This might lead to passing ofimproper and out-of-bounds page size which could result inmemory issue. Calculate page start and page end using the offsetadjusted address instead of absolute address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFC: nci: Add bounds checking in nci_hci_create_pipe()The "pipe" variable is a u8 which comes from the network. If it's morethan 127, then it results in memory corruption in the caller,nci_hci_connect_gate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21736 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix possible int overflows in nilfs_fiemap()Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its resultby being prepared to go through potentially maxblocks == INT_MAX blocks,the value in n may experience an overflow caused by left shift of blkbits.While it is extremely unlikely to occur, play it safe and cast right handexpression to wider type to mitigate the issue.Found by Linux Verification Center (linuxtesting.org) with static analysistool SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix NULL pointer dereference in brcmf_txfinalize()On removal of the device or unloading of the kernel module a potential NULLpointer dereference occurs.The following sequence deletes the interface: brcmf_detach() brcmf_remove_interface() brcmf_del_if()Inside the brcmf_del_if() function the drvr->if2bss[ifidx] is updated toBRCMF_BSSIDX_INVALID (-1) if the bsscfgidx matches.After brcmf_remove_interface() call the brcmf_proto_detach() function iscalled providing the following sequence: brcmf_detach() brcmf_proto_detach() brcmf_proto_msgbuf_detach() brcmf_flowring_detach() brcmf_msgbuf_delete_flowring() brcmf_msgbuf_remove_flowring() brcmf_flowring_delete() brcmf_get_ifp() brcmf_txfinalize()Since brcmf_get_ip() can and actually will return NULL in this case thecall to brcmf_txfinalize() will result in a NULL pointer dereference insidebrcmf_txfinalize() when trying to update ifp->ndev->stats.tx_errors.This will only happen if a flowring still has an skb.Although the NULL pointer dereference has only been seen when trying toupdate the tx statistic, all other uses of the ifp pointer have beenguarded as well with an early return if ifp is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21745 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix class @block_class's subsystem refcount leakageblkcg_fill_root_iostats() iterates over @block_class's devices byclass_dev_iter_(init|next)(), but does not end iterating withclass_dev_iter_exit(), so causes the class's subsystem refcount leakage.Fix by ending the iterating with class_dev_iter_exit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Check the return value of of_property_read_string_index()Somewhen between 6.10 and 6.11 the driver started to crash on myMacBookPro14,3. The property doesn't exist and 'tmp' remainsuninitialized, so we pass a random pointer to devm_kstrdup().The crash I am getting looks like this:BUG: unable to handle page fault for address: 00007f033c669379PF: supervisor read access in kernel modePF: error_code(0x0001) - permissions violationPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025Oops: Oops: 0001 [#1] SMP PTICPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024RIP: 0010:strlen+0x4/0x30Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 ccRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916aR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x149/0x4c0 ? raw_spin_rq_lock_nested+0xe/0x20 ? sched_balance_newidle+0x22b/0x3c0 ? update_load_avg+0x78/0x770 ? exc_page_fault+0x6f/0x150 ? asm_exc_page_fault+0x26/0x30 ? __pfx_pci_conf1_write+0x10/0x10 ? strlen+0x4/0x30 devm_kstrdup+0x25/0x70 brcmf_of_probe+0x273/0x350 [brcmfmac]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21758 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: add RCU protection to mld_newpack()mld_newpack() can be called without RTNL or RCU being held.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21759 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: extend RCU protection in igmp6_send()igmp6_send() can be called without RTNL or RCU being held.Extend RCU protection so that we can safely fetch the net pointerand avoid a potential UAF.Note that we no longer can use sock_alloc_send_skb() becauseipv6.igmp_sk uses GFP_KERNEL allocations which can sleep.Instead use alloc_skb() and charge the net->ipv6.igmp_sksocket under RCU protection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21760 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: extend RCU protection in ndisc_send_skb()ndisc_send_skb() can be called without RTNL or RCU held.Acquire rcu_read_lock() earlier, so that we can use dev_net_rcu()and avoid a potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21761 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: use RCU protection in ovs_vport_cmd_fill_info()ovs_vport_cmd_fill_info() can be called without RTNL or RCU.Use RCU protection and dev_net_rcu() to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arp: use RCU protection in arp_xmit()arp_xmit() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21763 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:neighbour: use RCU protection in __neigh_notify()__neigh_notify() can be called without RTNL or RCU protection.Use RCU protection to avoid potential UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ndisc: use RCU protection in ndisc_alloc_skb()ndisc_alloc_skb() can be called without RTNL or RCU being held.Add RCU protection to avoid possible UAF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: use RCU protection in ip6_default_advmss()ip6_default_advmss() needs rcu protection to makesure the net structure it reads does not disappear.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: use RCU protection in __ip_rt_update_pmtu()__ip_rt_update_pmtu() must use RCU protection to makesure the net structure it reads does not disappear.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic contextThe following bug report happened with a PREEMPT_RT kernel: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0It is due to the fact that clocksource_verify_choose_cpus() is invoked withpreemption disabled. This function invokes get_random_u32() to obtainrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/orthe base_crng.lock spinlock in driver/char/random.c will be acquired duringthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannotbe acquired in atomic context.Fix this problem by using migrate_disable() to allow smp_processor_id() tobe reliably used without introducing atomic context. preempt_disable() isthen called after clocksource_verify_choose_cpus() but before theclocksource measurement is being run to avoid introducing unexpectedlatency.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix dst ref loops in rpl, seg6 and ioam6 lwtunnelsSome lwtunnels have a dst cache for post-transformation dst.If the packet destination did not change we may end up recordinga reference to the lwtunnel in its own cache, and the lwtunnelstate will never be freed.Discovered by the ioam6.sh test, kmemleak was recently fixedto catch per-cpu memory leaks. I'm not sure if rpl and seg6can actually hit this, but in principle I don't see why not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21776 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: hub: Ignore non-compliant devices with too many configs or interfacesRobert Morris created a test program which can causeusb_hub_to_struct_hub() to dereference a NULL or inappropriatepointer:Oops: general protection fault, probably for non-canonical address0xcccccccccccccccc: 0000 [#1] SMP DEBUG_PAGEALLOC PTICPU: 7 UID: 0 PID: 117 Comm: kworker/7:1 Not tainted 6.13.0-rc3-00017-gf44d154d6e3d #14Hardware name: FreeBSD BHYVE/BHYVE, BIOS 14.0 10/17/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:usb_hub_adjust_deviceremovable+0x78/0x110...Call Trace: ? die_addr+0x31/0x80 ? exc_general_protection+0x1b4/0x3c0 ? asm_exc_general_protection+0x26/0x30 ? usb_hub_adjust_deviceremovable+0x78/0x110 hub_probe+0x7c7/0xab0 usb_probe_interface+0x14b/0x350 really_probe+0xd0/0x2d0 ? __pfx___device_attach_driver+0x10/0x10 __driver_probe_device+0x6e/0x110 driver_probe_device+0x1a/0x90 __device_attach_driver+0x7e/0xc0 bus_for_each_drv+0x7f/0xd0 __device_attach+0xaa/0x1a0 bus_probe_device+0x8b/0xa0 device_add+0x62e/0x810 usb_set_configuration+0x65d/0x990 usb_generic_driver_probe+0x4b/0x70 usb_probe_device+0x36/0xd0The cause of this error is that the device has two interfaces, and thehub driver binds to interface 1 instead of interface 0, which is whereusb_hub_to_struct_hub() looks.We can prevent the problem from occurring by refusing to accept hubdevices that violate the USB spec by having more than oneconfiguration or interface.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernelAdvertise support for Hyper-V's SEND_IPI and SEND_IPI_EX hypercalls if andonly if the local API is emulated/virtualized by KVM, and explicitly rejectsaid hypercalls if the local APIC is emulated in userspace, i.e. don't relyon userspace to opt-in to KVM_CAP_HYPERV_ENFORCE_CPUID.Rejecting SEND_IPI and SEND_IPI_EX fixes a NULL-pointer dereference ifHyper-V enlightenments are exposed to the guest without an in-kernel localAPIC: dump_stack+0xbe/0xfd __kasan_report.cold+0x34/0x84 kasan_report+0x3a/0x50 __apic_accept_irq+0x3a/0x5c0 kvm_hv_send_ipi.isra.0+0x34e/0x820 kvm_hv_hypercall+0x8d9/0x9d0 kvm_emulate_hypercall+0x506/0x7e0 __vmx_handle_exit+0x283/0xb60 vmx_handle_exit+0x1d/0xd0 vcpu_enter_guest+0x16b0/0x24c0 vcpu_run+0xc0/0x550 kvm_arch_vcpu_ioctl_run+0x170/0x6d0 kvm_vcpu_ioctl+0x413/0xb20 __se_sys_ioctl+0x111/0x160 do_syscal1_64+0x30/0x40 entry_SYSCALL_64_after_hwframe+0x67/0xd1Note, checking the sending vCPU is sufficient, as the per-VM irqchip_modecan't be modified after vCPUs are created, i.e. if one vCPU has anin-kernel local APIC, then all vCPUs have an in-kernel local APIC.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix panic during interface removalReference counting is used to ensure thatbatadv_hardif_neigh_node and batadv_hard_ifaceare not freed before/duringbatadv_v_elp_throughput_metric_update work isfinished.But there isn't a guarantee that the hard if willremain associated with a soft interface up untilthe work is finished.This fixes a crash triggered by reboot that lookslike this:Call trace: batadv_v_mesh_free+0xd0/0x4dc [batman_adv] batadv_v_elp_throughput_metric_update+0x1c/0xa4 process_one_work+0x178/0x398 worker_thread+0x2e8/0x4d0 kthread+0xd8/0xdc ret_from_fork+0x10/0x20(the batadv_v_mesh_free call is misleading,and does not actually happen)I was able to make the issue happen more reliablyby changing hardif_neigh->bat_v.metric_work workto be delayed work. This allowed me to track downand confirm the fix.[sven@narfation.org: prevent entering batadv_v_elp_get_throughput without soft_iface]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:team: better TEAM_OPTION_TYPE_STRING validationsyzbot reported following splat [1]Make sure user-provided data contains one nul byte.[1] BUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:633 [inline] BUG: KMSAN: uninit-value in string+0x3ec/0x5f0 lib/vsprintf.c:714 string_nocheck lib/vsprintf.c:633 [inline] string+0x3ec/0x5f0 lib/vsprintf.c:714 vsnprintf+0xa5d/0x1960 lib/vsprintf.c:2843 __request_module+0x252/0x9f0 kernel/module/kmod.c:149 team_mode_get drivers/net/team/team_core.c:480 [inline] team_change_mode drivers/net/team/team_core.c:607 [inline] team_mode_option_set+0x437/0x970 drivers/net/team/team_core.c:1401 team_option_set drivers/net/team/team_core.c:375 [inline] team_nl_options_set_doit+0x1339/0x1f90 drivers/net/team/team_core.c:2662 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x1214/0x12c0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2543 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0xf52/0x1260 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x10da/0x11e0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:733 ____sys_sendmsg+0x877/0xb60 net/socket.c:2573 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2627 __sys_sendmsg net/socket.c:2659 [inline] __do_sys_sendmsg net/socket.c:2664 [inline] __se_sys_sendmsg net/socket.c:2662 [inline] __x64_sys_sendmsg+0x212/0x3c0 net/socket.c:2662 x64_sys_call+0x2ed6/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21792 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount leak caused by setting SO_BINDTODEVICE sockoptIf an AX25 device is bound to a socket by setting the SO_BINDTODEVICEsocket option, a refcount leak will occur in ax25_release().Commit 9fd75b66b8f6 ("ax25: Fix refcount leaks caused by ax25_cb_del()")added decrement of device refcounts in ax25_release(). In order for thatto work correctly the refcounts must already be incremented when thedevice is bound to the socket. An AX25 device can be bound to a socketby either calling ax25_bind() or setting SO_BINDTODEVICE socket option.In both cases the refcounts should be incremented, but in fact it is doneonly in ax25_bind().This bug leads to the following issue reported by Syzkaller:================================================================refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 1 PID: 5932 at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Modules linked in:CPU: 1 UID: 0 PID: 5932 Comm: syz-executor424 Not tainted 6.13.0-rc4-syzkaller-00110-g4099a71718b0 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0x1ed/0x210 lib/refcount.c:31Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x710/0x820 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4156 [inline] netdev_put include/linux/netdevice.h:4173 [inline] netdev_put include/linux/netdevice.h:4169 [inline] ax25_release+0x33f/0xa10 net/ax25/af_ax25.c:1069 __sock_release+0xb0/0x270 net/socket.c:640 sock_close+0x1c/0x30 net/socket.c:1408 ... do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Fix the implementation of ax25_setsockopt() by adding increment ofrefcounts for the new device bound, and decrement of refcounts forthe old unbound device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: clear acl_access/acl_default after releasing themIf getting acl_default fails, acl_access and acl_default will be releasedsimultaneously. However, acl_access will still retain a pointer pointingto the released posix_acl, which will trigger a WARNING innfs3svc_release_getacl like this:------------[ cut here ]------------refcount_t: underflow; use-after-free.WARNING: CPU: 26 PID: 3199 at lib/refcount.c:28refcount_warn_saturate+0xb5/0x170Modules linked in:CPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted6.12.0-rc6-00079-g04ae226af01f-dirty #8Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.1-2.fc37 04/01/2014RIP: 0010:refcount_warn_saturate+0xb5/0x170Code: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75e4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b ebcd 0f b6 1d 8a3RSP: 0018:ffffc90008637cd8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fdeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380RBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56R10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001R13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0FS: 0000000000000000(0000) GS:ffff88871ed00000(0000)knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? refcount_warn_saturate+0xb5/0x170 ? __warn+0xa5/0x140 ? refcount_warn_saturate+0xb5/0x170 ? report_bug+0x1b1/0x1e0 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? tick_nohz_tick_stopped+0x1e/0x40 ? refcount_warn_saturate+0xb5/0x170 ? refcount_warn_saturate+0xb5/0x170 nfs3svc_release_getacl+0xc9/0xe0 svc_process_common+0x5db/0xb60 ? __pfx_svc_process_common+0x10/0x10 ? __rcu_read_unlock+0x69/0xa0 ? __pfx_nfsd_dispatch+0x10/0x10 ? svc_xprt_received+0xa1/0x120 ? xdr_init_decode+0x11d/0x190 svc_process+0x2a7/0x330 svc_handle_xprt+0x69d/0x940 svc_recv+0x180/0x2d0 nfsd+0x168/0x200 ? __pfx_nfsd+0x10/0x10 kthread+0x1a2/0x1e0 ? kthread+0xf4/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Kernel panic - not syncing: kernel: panic_on_warn set ...Clear acl_access/acl_default after posix_acl_release is called to preventUAF from being triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21799 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ethernet: ti: am65-cpsw: fix freeing IRQ in am65_cpsw_nuss_remove_tx_chns()When getting the IRQ we use k3_udma_glue_tx_get_irq() which returnsnegative error value on error. So not NULL check is not sufficientto deteremine if IRQ is valid. Check that IRQ is greater then zeroto ensure it is valid.There is no issue at probe time but at runtime user can invoke.set_channels which results in the following call chain.am65_cpsw_set_channels() am65_cpsw_nuss_update_tx_rx_chns() am65_cpsw_nuss_remove_tx_chns() am65_cpsw_nuss_init_tx_chns()At this point if am65_cpsw_nuss_init_tx_chns() fails due tok3_udma_glue_tx_get_irq() then tx_chn->irq will be set to anegative value.Then, at subsequent .set_channels with higher channel count wewill attempt to free an invalid IRQ in am65_cpsw_nuss_remove_tx_chns()leading to a kernel warning.The issue is present in the original commit that introduced this driver,although there, am65_cpsw_nuss_update_tx_rx_chns() existed asam65_cpsw_nuss_update_tx_chns().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21801 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ravb: Fix missing rtnl lock in suspend/resume pathFix the suspend/resume path by ensuring the rtnl lock is held whererequired. Calls to ravb_open, ravb_close and wol operations must beperformed under the rtnl lock to prevent conflicts with ongoing ndooperations.Without this fix, the following warning is triggered:[ 39.032969] =============================[ 39.032983] WARNING: suspicious RCU usage[ 39.033019] -----------------------------[ 39.033033] drivers/net/phy/phy_device.c:2004 suspiciousrcu_dereference_protected() usage!...[ 39.033597] stack backtrace:[ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7[ 39.033623] Hardware name: Renesas SMARC EVK version 2 based onr9a08g045s33 (DT)[ 39.033628] Call trace:[ 39.033633] show_stack+0x14/0x1c (C)[ 39.033652] dump_stack_lvl+0xb4/0xc4[ 39.033664] dump_stack+0x14/0x1c[ 39.033671] lockdep_rcu_suspicious+0x16c/0x22c[ 39.033682] phy_detach+0x160/0x190[ 39.033694] phy_disconnect+0x40/0x54[ 39.033703] ravb_close+0x6c/0x1cc[ 39.033714] ravb_suspend+0x48/0x120[ 39.033721] dpm_run_callback+0x4c/0x14c[ 39.033731] device_suspend+0x11c/0x4dc[ 39.033740] dpm_suspend+0xdc/0x214[ 39.033748] dpm_suspend_start+0x48/0x60[ 39.033758] suspend_devices_and_enter+0x124/0x574[ 39.033769] pm_suspend+0x1ac/0x274[ 39.033778] state_store+0x88/0x124[ 39.033788] kobj_attr_store+0x14/0x24[ 39.033798] sysfs_kf_write+0x48/0x6c[ 39.033808] kernfs_fop_write_iter+0x118/0x1a8[ 39.033817] vfs_write+0x27c/0x378[ 39.033825] ksys_write+0x64/0xf4[ 39.033833] __arm64_sys_write+0x18/0x20[ 39.033841] invoke_syscall+0x44/0x104[ 39.033852] el0_svc_common.constprop.0+0xb4/0xd4[ 39.033862] do_el0_svc+0x18/0x20[ 39.033870] el0_svc+0x3c/0xf0[ 39.033880] el0t_64_sync_handler+0xc0/0xc4[ 39.033888] el0t_64_sync+0x154/0x158[ 39.041274] ravb 11c30000.ethernet eth0: Link is Down

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21802 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix oops when unload drivers parallelingWhen unload hclge driver, it tries to disable sriov first for eachae_dev node from hnae3_ae_dev_list. If user unloads hns3 driver atthe time, because it removes all the ae_dev nodes, and it may causeoops.But we can't simply use hnae3_common_lock for this. Because in theprocess flow of pci_disable_sriov(), it will trigger the remove flowof VF, which will also take hnae3_common_lock.To fixes it, introduce a new mutex to protect the unload process.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21804 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: rcar-ep: Fix incorrect variable used when calling devm_request_mem_region()The rcar_pcie_parse_outbound_ranges() uses the devm_request_mem_region()macro to request a needed resource. A string variable that lives on thestack is then used to store a dynamically computed resource name, whichis then passed on as one of the macro arguments. This can lead toundefined behavior.Depending on the current contents of the memory, the manifestations oferrors may vary. One possible output may be as follows: $ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :Sometimes, garbage may appear after the colon.In very rare cases, if no NULL-terminator is found in memory, the systemmight crash because the string iterator will overrun which can lead toaccess of unmapped memory above the stack.Thus, fix this by replacing outbound_name with the name of the previouslyrequested resource. With the changes applied, the output will be asfollows: $ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21806 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: let net.core.dev_weight always be non-zeroThe following problem was encountered during stability test:(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \ returned 1, exceeding its budget of 0.------------[ cut here ]------------list_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \ next=ffff88905f746e40.WARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \ __list_add_valid_or_report+0xf3/0x130CPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+RIP: 0010:__list_add_valid_or_report+0xf3/0x130Call Trace:? __warn+0xcd/0x250? __list_add_valid_or_report+0xf3/0x130enqueue_to_backlog+0x923/0x1070netif_rx_internal+0x92/0x2b0__netif_rx+0x15/0x170loopback_xmit+0x2ef/0x450dev_hard_start_xmit+0x103/0x490__dev_queue_xmit+0xeac/0x1950ip_finish_output2+0x6cc/0x1620ip_output+0x161/0x270ip_push_pending_frames+0x155/0x1a0raw_sendmsg+0xe13/0x1550__sys_sendto+0x3bf/0x4e0__x64_sys_sendto+0xdc/0x1b0do_syscall_64+0x5b/0x170entry_SYSCALL_64_after_hwframe+0x76/0x7eThe reproduction command is as follows: sysctl -w net.core.dev_weight=0 ping 127.0.0.1This is because when the napi's weight is set to 0, process_backlog() mayreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing thisnapi to be re-polled in net_rx_action() until __do_softirq() times out.Since the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() canbe retriggered in enqueue_to_backlog(), causing this issue.Making the napi's weight always non-zero solves this problem.Triggering this issue requires system-wide admin (setting isnot namespaced).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21814 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Ensure info->enable callback is always setThe ioctl and sysfs handlers unconditionally call the ->enable callback.Not all drivers implement that callback, leading to NULL dereferences.Example of affected drivers: ptp_s390.c, ptp_vclock.c and ptp_mock.c.Instead use a dummy callback if no better was specified by the driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: xilinx_uartps: split sysrq handlinglockdep detects the following circular locking dependency:CPU 0 CPU 1========================== ============================cdns_uart_isr() printk() uart_port_lock(port) console_lock() cdns_uart_console_write() if (!port->sysrq) uart_port_lock(port) uart_handle_break() port->sysrq = ... uart_handle_sysrq_char() printk() console_lock()The fixed commit attempts to avoid this situation by only taking theport lock in cdns_uart_console_write if port->sysrq unset. However, if(as shown above) cdns_uart_console_write runs before port->sysrq is set,then it will try to take the port lock anyway. This may result in adeadlock.Fix this by splitting sysrq handling into two parts. We use the preparehelper under the port lock and defer handling until we release the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omap: use threaded IRQ for LCD DMAWhen using touchscreen and framebuffer, Nokia 770 crashes easily with: BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000 Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2 Hardware name: Nokia 770 Call trace: unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x54/0x5c dump_stack_lvl from __schedule_bug+0x50/0x70 __schedule_bug from __schedule+0x4d4/0x5bc __schedule from schedule+0x34/0xa0 schedule from schedule_preempt_disabled+0xc/0x10 schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4 __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4 clk_prepare_lock from clk_set_rate+0x18/0x154 clk_set_rate from sossi_read_data+0x4c/0x168 sossi_read_data from hwa742_read_reg+0x5c/0x8c hwa742_read_reg from send_frame_handler+0xfc/0x300 send_frame_handler from process_pending_requests+0x74/0xd0 process_pending_requests from lcd_dma_irq_handler+0x50/0x74 lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130 __handle_irq_event_percpu from handle_irq_event+0x28/0x68 handle_irq_event from handle_level_irq+0x9c/0x170 handle_level_irq from generic_handle_domain_irq+0x2c/0x3c generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c generic_handle_arch_irq from call_with_stack+0x1c/0x24 call_with_stack from __irq_svc+0x94/0xa8 Exception stack(0xc5255da0 to 0xc5255de8) 5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248 5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94 5de0: 60000013 ffffffff __irq_svc from clk_prepare_lock+0x4c/0xe4 clk_prepare_lock from clk_get_rate+0x10/0x74 clk_get_rate from uwire_setup_transfer+0x40/0x180 uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664 spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498 __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8 __spi_sync from spi_sync+0x24/0x40 spi_sync from ads7846_halfd_read_state+0x5c/0x1c0 ads7846_halfd_read_state from ads7846_irq+0x58/0x348 ads7846_irq from irq_thread_fn+0x1c/0x78 irq_thread_fn from irq_thread+0x120/0x228 irq_thread from kthread+0xc8/0xe8 kthread from ret_from_fork+0x14/0x28As a quick fix, switch to a threaded IRQ which provides a stable system.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: Drop unmanaged ELP metric workerThe ELP worker needs to calculate new metric values for all neighbors"reachable" over an interface. Some of the used metric sources requirelocks which might need to sleep. This sleep is incompatible with the RCUlist iterator used for the recorded neighbors. The initial approach to workaround of this problem was to queue another work item per neighbor and thenrun this in a new context.Even when this solved the RCU vs might_sleep() conflict, it has a majorproblems: Nothing was stopping the work item in case it is not neededanymore - for example because one of the related interfaces was removed orthe batman-adv module was unloaded - resulting in potential invalid memoryaccesses.Directly canceling the metric worker also has various problems:* cancel_work_sync for a to-be-deactivated interface is called with rtnl_lock held. But the code in the ELP metric worker also tries to use rtnl_lock() - which will never return in this case. This also means that cancel_work_sync would never return because it is waiting for the worker to finish.* iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)The better approch is to get rid of the per interface neighbor metricworker and handle everything in the interface worker. The original problemsare solved by:* creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context* only use rcu_trylock inside metric gathering code to avoid a deadlock when the cancel_delayed_work_sync is called in the interface removal code (which is called with the rtnl_lock held)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:landlock: Handle weird filesA corrupted filesystem (e.g. bcachefs) might return weird files.Instead of throwing a warning and allowing access to such file, treatthem as regular files.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21831 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Avoid putting some root ports into D3 on TUXEDO Sirius Gen1commit 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") sets thepolicy that all PCIe ports are allowed to use D3. When the system issuspended if the port is not power manageable by the platform and won't beused for wakeup via a PME this sets up the policy for these ports to gointo D3hot.This policy generally makes sense from an OSPM perspective but it leads toproblems with wakeup from suspend on the TUXEDO Sirius 16 Gen 1 with aspecific old BIOS. This manifests as a system hang.On the affected Device + BIOS combination, add a quirk for the root port ofthe problematic controller to ensure that these root ports are not put intoD3hot at suspend.This patch is based on https://lore.kernel.org/linux-pci/20230708214457.1229-2-mario.limonciello@amd.combut with the added condition both in the documentation and in the code toapply only to the TUXEDO Sirius 16 Gen 1 with a specific old BIOS and onlythe affected root ports.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_midi: fix MIDI Streaming descriptor lengthsWhile the MIDI jacks are configured correctly, and the MIDIStreamingendpoint descriptors are filled with the correct information,bNumEmbMIDIJack and bLength are set incorrectly in these descriptors.This does not matter when the numbers of in and out ports are equal, butwhen they differ the host will receive broken descriptors withuninitialized stack memory leaking into the descriptor for whichevervalue is smaller.The precise meaning of "in" and "out" in the port counts is not clearlydefined and can be confusing. But elsewhere the driver consistentlyuses this to match the USB meaning of IN and OUT viewed from the host,so that "in" ports send data to the host and "out" ports receive datafrom it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Add check for next_buffer in receive_encrypted_standard()Add check for the return value of cifs_buf_get() and cifs_small_buf_get()in receive_encrypted_standard() to prevent null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21846 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acct: perform last write from workqueueIn [1] it was reported that the acct(2) system call can be used totrigger NULL deref in cases where it is set to write to a file thattriggers an internal lookup. This can e.g., happen when pointing acc(2)to /sys/power/resume. At the point the where the write to this filehappens the calling task has already exited and called exit_fs(). Alookup will thus trigger a NULL-deref when accessing current->fs.Reorganize the code so that the the final write happens from theworkqueue but with the caller's credentials. This preserves the(strange) permission model and has almost no regression risk.This api should stop to exist though.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: bpf: Add check for nfp_app_ctrl_msg_alloc()Add check for the return value of nfp_app_ctrl_msg_alloc() innfp_bpf_cmsg_alloc() to prevent null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: avoid holding freeze_mutex during mmap operationWe use map->freeze_mutex to prevent races between map_freeze() andmemory mapping BPF map contents with writable permissions. The way wenaively do this means we'll hold freeze_mutex for entire duration of allthe mm and VMA manipulations, which is completely unnecessary. This canpotentially also lead to deadlocks, as reported by syzbot in [0].So, instead, hold freeze_mutex only during writeability checks, bump(proactively) "write active" count for the map, unlock the mutex andproceed with mmap logic. And only if something went wrong during mmaplogic, then undo that "write active" counter increment. [0] https://lore.kernel.org/bpf/678dcbc9.050a0220.303755.0066.GAE@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: Fix use-after-free in geneve_find_dev().syzkaller reported a use-after-free in geneve_find_dev() [0]without repro.geneve_configure() links struct geneve_dev.next tonet_generic(net, geneve_net_id)->geneve_list.The net here could differ from dev_net(dev) if IFLA_NET_NS_PID,IFLA_NET_NS_FD, or IFLA_TARGET_NETNSID is set.When dev_net(dev) is dismantled, geneve_exit_batch_rtnl() finallycalls unregister_netdevice_queue() for each dev in the netns,and later the dev is freed.However, its geneve_dev.next is still linked to the backend UDPsocket netns.Then, use-after-free will occur when another geneve dev is createdin the netns.Let's call geneve_dellink() instead in geneve_destroy_tunnels().[0]:BUG: KASAN: slab-use-after-free in geneve_find_dev drivers/net/geneve.c:1295 [inline]BUG: KASAN: slab-use-after-free in geneve_configure+0x234/0x858 drivers/net/geneve.c:1343Read of size 2 at addr ffff000054d6ee24 by task syz.1.4029/13441CPU: 1 UID: 0 PID: 13441 Comm: syz.1.4029 Not tainted 6.13.0-g0ad9617c78ac #24 dc35ca22c79fb82e8e7bc5c9c9adafea898b1e3dHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x38/0x50 arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xbc/0x108 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x16c/0x6f0 mm/kasan/report.c:489 kasan_report+0xc0/0x120 mm/kasan/report.c:602 __asan_report_load2_noabort+0x20/0x30 mm/kasan/report_generic.c:379 geneve_find_dev drivers/net/geneve.c:1295 [inline] geneve_configure+0x234/0x858 drivers/net/geneve.c:1343 geneve_newlink+0xb8/0x128 drivers/net/geneve.c:1634 rtnl_newlink_create+0x23c/0x868 net/core/rtnetlink.c:3795 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x618/0x838 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x5fc/0x8b0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:713 [inline] __sock_sendmsg net/socket.c:728 [inline] ____sys_sendmsg+0x410/0x6f8 net/socket.c:2568 ___sys_sendmsg+0x178/0x1d8 net/socket.c:2622 __sys_sendmsg net/socket.c:2654 [inline] __do_sys_sendmsg net/socket.c:2659 [inline] __se_sys_sendmsg net/socket.c:2657 [inline] __arm64_sys_sendmsg+0x12c/0x1c8 net/socket.c:2657 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x90/0x278 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x13c/0x250 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x54/0x70 arch/arm64/kernel/syscall.c:151 el0_svc+0x4c/0xa8 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x1a0 arch/arm64/kernel/entry.S:600Allocated by task 13247: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x30/0x68 mm/kasan/common.c:68 kasan_save_alloc_info+0x44/0x58 mm/kasan/generic.c:568 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x84/0xa0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4298 [inline] __kmalloc_node_noprof+0x2a0/0x560 mm/slub.c:4304 __kvmalloc_node_noprof+0x9c/0x230 mm/util.c:645 alloc_netdev_mqs+0xb8/0x11a0 net/core/dev.c:11470 rtnl_create_link+0x2b8/0xb50 net/core/rtnetlink.c:3604 rtnl_newlink_create+0x19c/0x868 net/core/rtnetlink.c:3780 __rtnl_newlink net/core/rtnetlink.c:3906 [inline] rtnl_newlink+0x1054/0x1630 net/core/rtnetlink.c:4021 rtnetlink_rcv_msg+0x61c/0x918 net/core/rtnetlink.c:6911 netlink_rcv_skb+0x1dc/0x398 net/netlink/af_netlink.c:2543 rtnetlink_rcv+0x34/0x50 net/core/rtnetlink.c:6938 netlink_unicast_kernel net/netlink/af_n---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: gadget: f_midi: f_midi_complete to call queue_workWhen using USB MIDI, a lock is attempted to be acquired twice through are-entrant call to f_midi_transmit, causing a deadlock.Fix it by using queue_work() to schedule the inner f_midi_transmit() viaa high priority work queue from the completion handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/migrate_device: don't add folio to be freed to LRU in migrate_device_finalize()If migration succeeded, we calledfolio_migrate_flags()->mem_cgroup_migrate() to migrate the memcg from theold to the new folio. This will set memcg_data of the old folio to 0.Similarly, if migration failed, memcg_data of the dst folio is left unset.If we call folio_putback_lru() on such folios (memcg_data == 0), we willadd the folio to be freed to the LRU, making memcg code unhappy. Runningthe hmm selftests: # ./hmm-tests ... # RUN hmm.hmm_device_private.migrate ... [ 102.078007][T14893] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x7ff27d200 pfn:0x13cc00 [ 102.079974][T14893] anon flags: 0x17ff00000020018(uptodate|dirty|swapbacked|node=0|zone=2|lastcpupid=0x7ff) [ 102.082037][T14893] raw: 017ff00000020018 dead000000000100 dead000000000122 ffff8881353896c9 [ 102.083687][T14893] raw: 00000007ff27d200 0000000000000000 00000001ffffffff 0000000000000000 [ 102.085331][T14893] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 102.087230][T14893] ------------[ cut here ]------------ [ 102.088279][T14893] WARNING: CPU: 0 PID: 14893 at ./include/linux/memcontrol.h:726 folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.090478][T14893] Modules linked in: [ 102.091244][T14893] CPU: 0 UID: 0 PID: 14893 Comm: hmm-tests Not tainted 6.13.0-09623-g6c216bc522fd #151 [ 102.093089][T14893] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 [ 102.094848][T14893] RIP: 0010:folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.096104][T14893] Code: ... [ 102.099908][T14893] RSP: 0018:ffffc900236c37b0 EFLAGS: 00010293 [ 102.101152][T14893] RAX: 0000000000000000 RBX: ffffea0004f30000 RCX: ffffffff8183f426 [ 102.102684][T14893] RDX: ffff8881063cb880 RSI: ffffffff81b8117f RDI: ffff8881063cb880 [ 102.104227][T14893] RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000000 [ 102.105757][T14893] R10: 0000000000000001 R11: 0000000000000002 R12: ffffc900236c37d8 [ 102.107296][T14893] R13: ffff888277a2bcb0 R14: 000000000000001f R15: 0000000000000000 [ 102.108830][T14893] FS: 00007ff27dbdd740(0000) GS:ffff888277a00000(0000) knlGS:0000000000000000 [ 102.110643][T14893] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 102.111924][T14893] CR2: 00007ff27d400000 CR3: 000000010866e000 CR4: 0000000000750ef0 [ 102.113478][T14893] PKRU: 55555554 [ 102.114172][T14893] Call Trace: [ 102.114805][T14893] [ 102.115397][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.116547][T14893] ? __warn.cold+0x110/0x210 [ 102.117461][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.118667][T14893] ? report_bug+0x1b9/0x320 [ 102.119571][T14893] ? handle_bug+0x54/0x90 [ 102.120494][T14893] ? exc_invalid_op+0x17/0x50 [ 102.121433][T14893] ? asm_exc_invalid_op+0x1a/0x20 [ 102.122435][T14893] ? __wake_up_klogd.part.0+0x76/0xd0 [ 102.123506][T14893] ? dump_page+0x4f/0x60 [ 102.124352][T14893] ? folio_lruvec_lock_irqsave+0x10e/0x170 [ 102.125500][T14893] folio_batch_move_lru+0xd4/0x200 [ 102.126577][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.127505][T14893] __folio_batch_add_and_move+0x391/0x720 [ 102.128633][T14893] ? __pfx_lru_add+0x10/0x10 [ 102.129550][T14893] folio_putback_lru+0x16/0x80 [ 102.130564][T14893] migrate_device_finalize+0x9b/0x530 [ 102.131640][T14893] dmirror_migrate_to_device.constprop.0+0x7c5/0xad0 [ 102.133047][T14893] dmirror_fops_unlocked_ioctl+0x89b/0xc80Likely, nothing else goes wrong: putting the last folio reference willremove the folio from the LRU again. So besides memcg complaining, addingthe folio to be freed to the LRU is just an unnecessary step.The new flow resembles what we have in migrate_folio_move(): add the dstto the lru, rem---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: fix incorrect initialization orderSyzkaller reports the following bug:BUG: spinlock bad magic on CPU#1, syz-executor.0/7995 lock: 0xffff88805303f3e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0CPU: 1 PID: 7995 Comm: syz-executor.0 Tainted: G E 5.10.209+ #1Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x119/0x179 lib/dump_stack.c:118 debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline] do_raw_spin_lock+0x1f6/0x270 kernel/locking/spinlock_debug.c:112 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:117 [inline] _raw_spin_lock_irqsave+0x50/0x70 kernel/locking/spinlock.c:159 reset_per_cpu_data+0xe6/0x240 [drop_monitor] net_dm_cmd_trace+0x43d/0x17a0 [drop_monitor] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2497 genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x914/0xe00 net/netlink/af_netlink.c:1916 sock_sendmsg_nosec net/socket.c:651 [inline] __sock_sendmsg+0x157/0x190 net/socket.c:663 ____sys_sendmsg+0x712/0x870 net/socket.c:2378 ___sys_sendmsg+0xf8/0x170 net/socket.c:2432 __sys_sendmsg+0xea/0x1b0 net/socket.c:2461 do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x62/0xc7RIP: 0033:0x7f3f9815aee9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f3f972bf0c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f3f9826d050 RCX: 00007f3f9815aee9RDX: 0000000020000000 RSI: 0000000020001300 RDI: 0000000000000007RBP: 00007f3f981b63bd R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000006e R14: 00007f3f9826d050 R15: 00007ffe01ee6768If drop_monitor is built as a kernel module, syzkaller may have timeto send a netlink NET_DM_CMD_START message during the module loading.This will call the net_dm_monitor_start() function that usesa spinlock that has not yet been initialized.To fix this, let's place resource initialization above the registrationof a generic netlink family.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring: prevent opcode speculationsqe->opcode is used for different tables, make sure we santitise itagainst speculations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21866 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/code-patching: Fix KASAN hit by not flagging text patching area as VM_ALLOCErhard reported the following KASAN hit while booting his PowerMac G4with a KASAN-enabled kernel 6.13-rc6: BUG: KASAN: vmalloc-out-of-bounds in copy_to_kernel_nofault+0xd8/0x1c8 Write of size 8 at addr f1000000 by task chronyd/1293 CPU: 0 UID: 123 PID: 1293 Comm: chronyd Tainted: G W 6.13.0-rc6-PMacG4 #2 Tainted: [W]=WARN Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c2437590] [c1631a84] dump_stack_lvl+0x70/0x8c (unreliable) [c24375b0] [c0504998] print_report+0xdc/0x504 [c2437610] [c050475c] kasan_report+0xf8/0x108 [c2437690] [c0505a3c] kasan_check_range+0x24/0x18c [c24376a0] [c03fb5e4] copy_to_kernel_nofault+0xd8/0x1c8 [c24376c0] [c004c014] patch_instructions+0x15c/0x16c [c2437710] [c00731a8] bpf_arch_text_copy+0x60/0x7c [c2437730] [c0281168] bpf_jit_binary_pack_finalize+0x50/0xac [c2437750] [c0073cf4] bpf_int_jit_compile+0xb30/0xdec [c2437880] [c0280394] bpf_prog_select_runtime+0x15c/0x478 [c24378d0] [c1263428] bpf_prepare_filter+0xbf8/0xc14 [c2437990] [c12677ec] bpf_prog_create_from_user+0x258/0x2b4 [c24379d0] [c027111c] do_seccomp+0x3dc/0x1890 [c2437ac0] [c001d8e0] system_call_exception+0x2dc/0x420 [c2437f30] [c00281ac] ret_from_syscall+0x0/0x2c --- interrupt: c00 at 0x5a1274 NIP: 005a1274 LR: 006a3b3c CTR: 005296c8 REGS: c2437f40 TRAP: 0c00 Tainted: G W (6.13.0-rc6-PMacG4) MSR: 0200f932 CR: 24004422 XER: 00000000 GPR00: 00000166 af8f3fa0 a7ee3540 00000001 00000000 013b6500 005a5858 0200f932 GPR08: 00000000 00001fe9 013d5fc8 005296c8 2822244c 00b2fcd8 00000000 af8f4b57 GPR16: 00000000 00000001 00000000 00000000 00000000 00000001 00000000 00000002 GPR24: 00afdbb0 00000000 00000000 00000000 006e0004 013ce060 006e7c1c 00000001 NIP [005a1274] 0x5a1274 LR [006a3b3c] 0x6a3b3c --- interrupt: c00 The buggy address belongs to the virtual mapping at [f1000000, f1002000) created by: text_area_cpu_up+0x20/0x190 The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x76e30 flags: 0x80000000(zone=2) raw: 80000000 00000000 00000122 00000000 00000000 00000000 ffffffff 00000001 raw: 00000000 page dumped because: kasan: bad access detected Memory state around the buggy address: f0ffff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f0ffff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >f1000000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f1000080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f1000100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ==================================================================f8 corresponds to KASAN_VMALLOC_INVALID which means the area is notinitialised hence not supposed to be used yet.Powerpc text patching infrastructure allocates a virtual memory areausing get_vm_area() and flags it as VM_ALLOC. But that flag is meantto be used for vmalloc() and vmalloc() allocated memory is notsupposed to be used before a call to __vmalloc_node_range() which isnever called for that area.That went undetected until commit e4137f08816b ("mm, kasan, kmsan:instrument copy_from/to_kernel_nofault")The area allocated by text_area_cpu_up() is not vmalloc memory, it ismapped directly on demand when needed by map_kernel_page(). There isno VM flag corresponding to such usage, so just pass no flag. That waythe area will be unpoisonned and usable immediately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21871 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: optee: Fix supplicant wait loopOP-TEE supplicant is a user-space daemon and it's possible for itbe hung or crashed or killed in the middle of processing an OP-TEERPC call. It becomes more complicated when there is incorrect shutdownordering of the supplicant process vs the OP-TEE client application whichcan eventually lead to system hang-up waiting for the closure of theclient application.Allow the client process waiting in kernel for supplicant response tobe killed rather than indefinitely waiting in an unkillable state. Also,a normal uninterruptible wait should not have resulted in the hung-taskwatchdog getting triggered, but the endless loop would.This fixes issues observed during system reboot/shutdown when supplicantgot hung for some reason or gets crashed/killed which lead to clientgetting hung in an unkillable state. It in turn lead to system being inhung up state requiring hard power off/on to recover.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21872 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efi: Don't map the entire mokvar table to determine its sizeCurrently, when validating the mokvar table, we (re)map the entire tableon each iteration of the loop, adding space as we discover new entries.If the table grows over a certain size, this fails due to limitations ofearly_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... Call Trace: ? __early_ioremap+0xef/0x220 ? __warn.cold+0x93/0xfa ? __early_ioremap+0xef/0x220 ? report_bug+0xff/0x140 ? early_fixup_exception+0x5d/0xb0 ? early_idt_handler_common+0x2f/0x3a ? __early_ioremap+0xef/0x220 ? efi_mokvar_table_init+0xce/0x1d0 ? setup_arch+0x864/0xc10 ? start_kernel+0x6b/0xa10 ? x86_64_start_reservations+0x24/0x30 ? x86_64_start_kernel+0xed/0xf0 ? common_startup_64+0x13e/0x141 ---[ end trace 0000000000000000 ]--- mokvar: Failed to map EFI MOKvar config table pa=0x7c4c3000, size=265187.Mapping the entire structure isn't actually necessary, as we don't everneed more than one entry header mapped at once.Changes efi_mokvar_table_init() to only map each entry header, not theentire table, when determining the table size. Since we're not mappingany data past the variable name, it also changes the code to enforcethat each variable name is NUL terminated, rather than attempting toverify it in place.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: always handle address removal under msk socket lockSyzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Modules linked in: CPU: 0 UID: 0 PID: 6693 Comm: syz.0.205 Not tainted 6.14.0-rc2-syzkaller-00303-gad1b832bf1cf #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 12/27/2024 RIP: 0010:sock_owned_by_me include/net/sock.h:1711 [inline] RIP: 0010:msk_owned_by_me net/mptcp/protocol.h:363 [inline] RIP: 0010:mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:788 Code: 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ca 7b d3 f5 eb b9 e8 c3 7b d3 f5 90 0f 0b 90 e9 dd fb ff ff e8 b5 7b d3 f5 90 <0f> 0b 90 e9 3e fb ff ff 44 89 f1 80 e1 07 38 c1 0f 8c eb fb ff ff RSP: 0000:ffffc900034f6f60 EFLAGS: 00010283 RAX: ffffffff8bee3c2b RBX: 0000000000000001 RCX: 0000000000080000 RDX: ffffc90004d42000 RSI: 000000000000a407 RDI: 000000000000a408 RBP: ffffc900034f7030 R08: ffffffff8bee37f6 R09: 0100000000000000 R10: dffffc0000000000 R11: ffffed100bcc62e4 R12: ffff88805e6316e0 R13: ffff88805e630c00 R14: dffffc0000000000 R15: ffff88805e630c00 FS: 00007f7e9a7e96c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2fd18ff8 CR3: 0000000032c24000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: mptcp_pm_remove_addr+0x103/0x1d0 net/mptcp/pm.c:59 mptcp_pm_remove_anno_addr+0x1f4/0x2f0 net/mptcp/pm_netlink.c:1486 mptcp_nl_remove_subflow_and_signal_addr net/mptcp/pm_netlink.c:1518 [inline] mptcp_pm_nl_del_addr_doit+0x118d/0x1af0 net/mptcp/pm_netlink.c:1629 genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline] genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0xb1f/0xec0 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x206/0x480 net/netlink/af_netlink.c:2543 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1322 [inline] netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1348 netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1892 sock_sendmsg_nosec net/socket.c:718 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:733 ____sys_sendmsg+0x53a/0x860 net/socket.c:2573 ___sys_sendmsg net/socket.c:2627 [inline] __sys_sendmsg+0x269/0x350 net/socket.c:2659 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f7e9998cde9 Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f7e9a7e9038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007f7e99ba5fa0 RCX: 00007f7e9998cde9 RDX: 000000002000c094 RSI: 0000400000000000 RDI: 0000000000000007 RBP: 00007f7e99a0e2a0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f7e99ba5fa0 R15: 00007fff49231088Indeed the PM can try to send a RM_ADDR over a msk without acquiringfirst the msk socket lock.The bugged code-path comes from an early optimization: when thereare no subflows, the PM should (usually) not send RM_ADDRnotifications.The above statement is incorrect, as without locks another processcould concur---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21877 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: gl620a: fix endpoint checking in genelink_bind()Syzbot reports [1] a warning in usb_submit_urb() triggered byinconsistencies between expected and actually present endpointsin gl620a driver. Since genelink_bind() does not properlyverify whether specified eps are in fact provided by the device,in this case, an artificially manufactured one, one may get amismatch.Fix the issue by resorting to a usbnet utility functionusbnet_get_endpoints(), usually reserved for this very problem.Check for endpoints and return early before proceeding further ifany are missing.[1] Syzbot report:usb 5-1: Manufacturer: syzusb 5-1: SerialNumber: syzusb 5-1: config 0 descriptor??gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...------------[ cut here ]------------usb 5-1: BOGUS urb xfer, pipe 3 != type 1WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503Modules linked in:CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: mld mld_ifc_workRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503...Call Trace: usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:3827 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_resolve_output net/core/neighbour.c:1514 [inline] neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494 neigh_output include/net/neighbour.h:539 [inline] ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mld_send_cr net/ipv6/mcast.c:2120 [inline] mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651 process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: npcm: disable interrupt enable bit before devm_request_irqThe customer reports that there is a soft lockup issue related tothe i2c driver. After checking, the i2c module was doing a tx transferand the bmc machine reboots in the middle of the i2c transaction, the i2cmodule keeps the status without being reset.Due to such an i2c module status, the i2c irq handler keeps gettingtriggered since the i2c irq handler is registered in the kernel bootingprocess after the bmc machine is doing a warm rebooting.The continuous triggering is stopped by the soft lockup watchdog timer.Disable the interrupt enable bit in the i2c module before callingdevm_request_irq to fix this issue since the i2c relative status bitis read-only.Here is the soft lockup log.[ 28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1][ 28.183351] Modules linked in:[ 28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1[ 28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 28.208128] pc : __do_softirq+0xb0/0x368[ 28.212055] lr : __do_softirq+0x70/0x368[ 28.215972] sp : ffffff8035ebca00[ 28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780[ 28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0[ 28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b[ 28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff[ 28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000[ 28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2[ 28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250[ 28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434[ 28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198[ 28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40[ 28.290611] Call trace:[ 28.293052] __do_softirq+0xb0/0x368[ 28.296625] __irq_exit_rcu+0xe0/0x100[ 28.300374] irq_exit+0x14/0x20[ 28.303513] handle_domain_irq+0x68/0x90[ 28.307440] gic_handle_irq+0x78/0xb0[ 28.311098] call_on_irq_stack+0x20/0x38[ 28.315019] do_interrupt_handler+0x54/0x5c[ 28.319199] el1_interrupt+0x2c/0x4c[ 28.322777] el1h_64_irq_handler+0x14/0x20[ 28.326872] el1h_64_irq+0x74/0x78[ 28.330269] __setup_irq+0x454/0x780[ 28.333841] request_threaded_irq+0xd0/0x1b4[ 28.338107] devm_request_threaded_irq+0x84/0x100[ 28.342809] npcm_i2c_probe_bus+0x188/0x3d0[ 28.346990] platform_probe+0x6c/0xc4[ 28.350653] really_probe+0xcc/0x45c[ 28.354227] __driver_probe_device+0x8c/0x160[ 28.358578] driver_probe_device+0x44/0xe0[ 28.362670] __driver_attach+0x124/0x1d0[ 28.366589] bus_for_each_dev+0x7c/0xe0[ 28.370426] driver_attach+0x28/0x30[ 28.373997] bus_add_driver+0x124/0x240[ 28.377830] driver_register+0x7c/0x124[ 28.381662] __platform_driver_register+0x2c/0x34[ 28.386362] npcm_i2c_init+0x3c/0x5c[ 28.389937] do_one_initcall+0x74/0x230[ 28.393768] kernel_init_freeable+0x24c/0x2b4[ 28.398126] kernel_init+0x28/0x130[ 28.401614] ret_from_fork+0x10/0x20[ 28.405189] Kernel panic - not syncing: softlockup: hung tasks[ 28.411011] SMP: stopping secondary CPUs[ 28.414933] Kernel Offset: disabled[ 28.418412] CPU features: 0x00000000,00000802[ 28.427644] Rebooting in 20 seconds..

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Fix the page details for the srq created by kernel consumersWhile using nvme target with use_srq on, below kernel panic is noticed.[ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514)[ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI..[ 566.393799] [ 566.393807] ? __die_body+0x1a/0x60[ 566.393823] ? die+0x38/0x60[ 566.393835] ? do_trap+0xe4/0x110[ 566.393847] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393867] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393881] ? do_error_trap+0x7c/0x120[ 566.393890] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393911] ? exc_divide_error+0x34/0x50[ 566.393923] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393939] ? asm_exc_divide_error+0x16/0x20[ 566.393966] ? bnxt_qplib_alloc_init_hwq+0x1d4/0x580 [bnxt_re][ 566.393997] bnxt_qplib_create_srq+0xc9/0x340 [bnxt_re][ 566.394040] bnxt_re_create_srq+0x335/0x3b0 [bnxt_re][ 566.394057] ? srso_return_thunk+0x5/0x5f[ 566.394068] ? __init_swait_queue_head+0x4a/0x60[ 566.394090] ib_create_srq_user+0xa7/0x150 [ib_core][ 566.394147] nvmet_rdma_queue_connect+0x7d0/0xbe0 [nvmet_rdma][ 566.394174] ? lock_release+0x22c/0x3f0[ 566.394187] ? srso_return_thunk+0x5/0x5fPage size and shift info is set only for the user space SRQs.Set page size and page shift for kernel space SRQs also.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21890 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix checksums set in idpf_rx_rsc()idpf_rx_rsc() uses skb_transport_offset(skb) while the transport headeris not set yet.This triggers the following warning for CONFIG_DEBUG_NET=y builds.DEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))[ 69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth[ 69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S W 6.14.0-smp-DEV #1697[ 69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN[ 69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)[ 69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261687] ? report_bug (lib/bug.c:?)[ 69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)[ 69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)[ 69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)[ 69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf[ 69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf[ 69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf[ 69.261712] __napi_poll (net/core/dev.c:7194)[ 69.261716] net_rx_action (net/core/dev.c:7265)[ 69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)[ 69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)[ 69.261726] handle_softirqs (kernel/softirq.c:561)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21891 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvlan: ensure network headers are in skb linear partsyzbot found that ipvlan_process_v6_outbound() was assumingthe IPv6 network header isis present in skb->head [1]Add the needed pskb_network_may_pull() calls for bothIPv4 and IPv6 handlers.[1]BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_route_output_flags_noref net/ipv6/route.c:2616 [inline] ip6_route_output_flags+0x51/0x720 net/ipv6/route.c:2651 ip6_route_output include/net/ip6_route.h:93 [inline] ipvlan_route_v6_outbound+0x24e/0x520 drivers/net/ipvlan/ipvlan_core.c:476 ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:491 [inline] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:541 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:605 [inline] ipvlan_queue_xmit+0xd72/0x1780 drivers/net/ipvlan/ipvlan_core.c:671 ipvlan_start_xmit+0x5b/0x210 drivers/net/ipvlan/ipvlan_main.c:223 __netdev_start_xmit include/linux/netdevice.h:5150 [inline] netdev_start_xmit include/linux/netdevice.h:5159 [inline] xmit_one net/core/dev.c:3735 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3751 sch_direct_xmit+0x399/0xd40 net/sched/sch_generic.c:343 qdisc_restart net/sched/sch_generic.c:408 [inline] __qdisc_run+0x14da/0x35d0 net/sched/sch_generic.c:416 qdisc_run+0x141/0x4d0 include/net/pkt_sched.h:127 net_tx_action+0x78b/0x940 net/core/dev.c:5484 handle_softirqs+0x1a0/0x7c0 kernel/softirq.c:561 __do_softirq+0x14/0x1a kernel/softirq.c:595 do_softirq+0x9a/0x100 kernel/softirq.c:462 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:389 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x2758/0x57d0 net/core/dev.c:4611 dev_queue_xmit include/linux/netdevice.h:3311 [inline] packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3132 [inline] packet_sendmsg+0x93e0/0xa7e0 net/packet/af_packet.c:3164 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21894 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: VFs do not support HWTSTAMP_TX_ONESTEP_SYNCActually ENETC VFs do not support HWTSTAMP_TX_ONESTEP_SYNC because onlyENETC PF can access PMa_SINGLE_STEP registers. And there will be a crashif VFs are used to test one-step timestamp, the crash log as follows.[ 129.110909] Unable to handle kernel paging request at virtual address 00000000000080c0[ 129.287769] Call trace:[ 129.290219] enetc_port_mac_wr+0x30/0xec (P)[ 129.294504] enetc_start_xmit+0xda4/0xe74[ 129.298525] enetc_xmit+0x70/0xec[ 129.301848] dev_hard_start_xmit+0x98/0x118

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21898 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Avoid potential division by zero in function_stat_show()Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64}produce zero and skip stddev computation in that case.For now don't care about rec->counter * rec->counter overflow becauserec->time * rec->time overflow will likely happen earlier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21899 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix bad hist from corrupting named_triggers listThe following commands causes a crash: ~# cd /sys/kernel/tracing/events/rcu/rcu_callback ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger bash: echo: write error: Invalid argument ~# echo 'hist:name=bad:keys=common_pid' > triggerBecause the following occurs:event_trigger_write() { trigger_process_regex() { event_hist_trigger_parse() { data = event_trigger_alloc(..); event_trigger_register(.., data) { cmd_ops->reg(.., data, ..) [hist_register_trigger()] { data->ops->init() [event_hist_trigger_init()] { save_named_trigger(name, data) { list_add(&data->named_list, &named_triggers); } } } } ret = create_actions(); (return -EINVAL) if (ret) goto out_unreg;[..] ret = hist_trigger_enable(data, ...) { list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)[..] out_unreg: event_hist_unregister(.., data) { cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] { list_for_each_entry(iter, &file->triggers, list) { if (!hist_trigger_match(data, iter, named_data, false)) <- never matches continue; [..] test = iter; } if (test && test->ops->free) <<<-- test is NULL test->ops->free(test) [event_hist_trigger_free()] { [..] if (data->name) del_named_trigger(data) { list_del(&data->named_list); <<<<-- NEVER gets removed! } } } } [..] kfree(data); <<<-- frees item but it is still on listThe next time a hist with name is registered, it causes an u-a-f bug andthe kernel can crash.Move the code around such that if event_trigger_register() succeeds, thenext thing called is hist_trigger_enable() which adds it to the list.A bunch of actions is called if get_named_trigger_data() returns false.But that doesn't need to be called after event_trigger_register(), so itcan be moved up, allowing event_trigger_register() to be called justbefore hist_trigger_enable() keeping them together and allowing thefile->triggers to be properly populated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21904 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:caif_virtio: fix wrong pointer check in cfv_probe()del_vqs() frees virtqueues, therefore cfv->vq_tx pointer should be checkedfor NULL before calling it, not cfv->vdev. Also the current implementationis redundant because the pointer cfv->vdev is dereferenced before it ischecked for NULL.Fix this by checking cfv->vq_tx for NULL instead of cfv->vdev beforecalling del_vqs().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21905 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: limit printed string from FW fileThere's no guarantee here that the file is always with aNUL-termination, so reading the string may read beyond theend of the TLV. If that's the last TLV in the file, it canperhaps even read beyond the end of the file buffer.Fix that by limiting the print format to the size of thebuffer we have.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21909 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: reject cooked mode if it is set along with other flagsIt is possible to set both MONITOR_FLAG_COOK_FRAMES and MONITOR_FLAG_ACTIVEflags simultaneously on the same monitor interface from the userspace. Thiscauses a sub-interface to be created with no IEEE80211_SDATA_IN_DRIVER bitset because the monitor interface is in the cooked state and it takesprecedence over all other states. When the interface is then being deletedthe kernel calls WARN_ONCE() from check_sdata_in_driver() because of missingthat bit.Fix this by rejecting MONITOR_FLAG_COOK_FRAMES if it is set along withother flags.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21910 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: regulatory: improve invalid hints checkingSyzbot keeps reporting an issue [1] that occurs when erroneous symbolssent from userspace get through into user_alpha2[] viaregulatory_hint_user() call. Such invalid regulatory hints should berejected.While a sanity check from commit 47caf685a685 ("cfg80211: regulatory:reject invalid hints") looks to be enough to deter these very cases,there is a way to get around it due to 2 reasons.1) The way isalpha() works, symbols other than latin lower andupper letters may be used to determine a country/domain.For instance, greek letters will also be considered upper/lowerletters and for such characters isalpha() will return true as well.However, ISO-3166-1 alpha2 codes should only hold latincharacters.2) While processing a user regulatory request, betweenreg_process_hint_user() and regulatory_hint_user() there happens tobe a call to queue_regulatory_request() which modifies letters inrequest->alpha2[] with toupper(). This works fine for latin symbols,less so for weird letter characters from the second part of _ctype[].Syzbot triggers a warning in is_user_regdom_saved() by first sendingover an unexpected non-latin letter that gets malformed by toupper()into a character that ends up failing isalpha() check.Prevent this by enhancing is_an_alpha2() to ensure that incomingsymbols are latin letters and nothing else.[1] Syzbot report:------------[ cut here ]------------Unexpected user alpha2: A�WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 is_user_regdom_saved net/wireless/reg.c:440 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_alpha2 net/wireless/reg.c:3424 [inline]WARNING: CPU: 1 PID: 964 at net/wireless/reg.c:442 restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516Modules linked in:CPU: 1 UID: 0 PID: 964 Comm: kworker/1:2 Not tainted 6.12.0-rc5-syzkaller-00044-gc1e939a21eb1 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: events_power_efficient crda_timeout_workRIP: 0010:is_user_regdom_saved net/wireless/reg.c:440 [inline]RIP: 0010:restore_alpha2 net/wireless/reg.c:3424 [inline]RIP: 0010:restore_regulatory_settings+0x3c0/0x1e50 net/wireless/reg.c:3516...Call Trace: crda_timeout_work+0x27/0x50 net/wireless/reg.c:542 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa65/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f2/0x390 kernel/kthread.c:389 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:slimbus: messaging: Free transaction ID in delayed interrupt scenarioIn case of interrupt delay for any reason, slim_do_transfer()returns timeout error but the transaction ID (TID) is not freed.This results into invalid memory access insideqcom_slim_ngd_rx_msgq_cb() due to invalid TID.Fix the issue by freeing the TID in slim_do_transfer() beforereturning timeout error to avoid invalid memory access.Call trace:__memcpy_fromio+0x20/0x190qcom_slim_ngd_rx_msgq_cb+0x130/0x290 [slim_qcom_ngd_ctrl]vchan_complete+0x2a0/0x4a0tasklet_action_common+0x274/0x700tasklet_action+0x28/0x3c_stext+0x188/0x620run_ksoftirqd+0x34/0x74smpboot_thread_fn+0x1d8/0x464kthread+0x178/0x238ret_from_fork+0x10/0x20Code: aa0003e8 91000429 f100044a 3940002b (3800150b)---[ end trace 0fe00bec2b975c99 ]---Kernel panic - not syncing: Oops: Fatal exception in interrupt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21917 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Flush the notify_hotplug_workWhen performing continuous unbind/bind operations on the USB driversavailable on the Renesas RZ/G2L SoC, a kernel crash with the message"Unable to handle kernel NULL pointer dereference at virtual address"may occur. This issue points to the usbhsc_notify_hotplug() function.Flush the delayed work to avoid its execution when driver resources areunavailable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21919 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Fix potential memory corruption in child_cfs_rq_on_listchild_cfs_rq_on_list attempts to convert a 'prev' pointer to a cfs_rq.This 'prev' pointer can originate from struct rq's leaf_cfs_rq_list,making the conversion invalid and potentially leading to memorycorruption. Depending on the relative positions of leaf_cfs_rq_list andthe task group (tg) pointer within the struct, this can cause a memoryfault or access garbage data.The issue arises in list_add_leaf_cfs_rq, where bothcfs_rq->leaf_cfs_rq_list and rq->leaf_cfs_rq_list are added to the sameleaf list. Also, rq->tmp_alone_branch can be set to rq->leaf_cfs_rq_list.This adds a check `if (prev == &rq->leaf_cfs_rq_list)` after the mainconditional in child_cfs_rq_on_list. This ensures that the container_ofoperation will convert a correct cfs_rq struct.This check is sufficient because only cfs_rqs on the same CPU are addedto the list, so verifying the 'prev' pointer against the current rq's listhead is enough.Fixes a potential memory corruption issue that due to current structlayout might not be manifesting as a crash but could lead to unpredictablebehavior when the layout changes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21920 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vlan: enforce underlying device typeCurrently, VLAN devices can be created on top of non-ethernet devices.Besides the fact that it doesn't make much sense, this also causes abug which leaks the address of a kernel function to usermode.When creating a VLAN device, we initialize GARP (garp_init_applicant)and MRP (mrp_init_applicant) for the underlying device.As part of the initialization process, we add the multicast address ofeach applicant to the underlying device, by calling dev_mc_add.__dev_mc_add uses dev->addr_len to determine the length of the newmulticast address.This causes an out-of-bounds read if dev->addr_len is greater than 6,since the multicast addresses provided by GARP and MRP are only 6bytes long.This behaviour can be reproduced using the following commands:ip tunnel add gretest mode ip6gre local ::1 remote ::2 dev loip l set up dev gretestip link add link gretest name vlantest type vlan id 100Then, the following command will display the address of garp_pdu_rcv:ip maddr show | grep 01:80:c2:00:00:21Fix the bug by enforcing the type of the underlying device during VLANdevice initialization.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21924 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: make sure ptp clock is unregister and freed if hclge_ptp_get_cycle returns an errorDuring the initialization of ptp, hclge_ptp_get_cycle might return an errorand returned directly without unregister clock and free it. To avoid that,call hclge_ptp_destroy_clock to unregist and free clock ifhclge_ptp_get_cycle failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21925 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:llc: do not use skb_get() before dev_queue_xmit()syzbot is able to crash hosts [1], using llc and devicesnot supporting IFF_TX_SKB_SHARING.In this case, e1000 driver calls eth_skb_pad(), whilethe skb is shared.Simply replace skb_get() by skb_clone() in net/llc/llc_s_ac.cNote that e1000 driver might have an issue with pktgen,because it does not clear IFF_TX_SKB_SHARING, this is anorthogonal change.We need to audit other skb_get() uses in net/llc.[1]kernel BUG at net/core/skbuff.c:2178 !Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 16371 Comm: syz.2.2764 Not tainted 6.14.0-rc4-syzkaller-00052-gac9c34d1e45a #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:pskb_expand_head+0x6ce/0x1240 net/core/skbuff.c:2178Call Trace: __skb_pad+0x18a/0x610 net/core/skbuff.c:2466 __skb_put_padto include/linux/skbuff.h:3843 [inline] skb_put_padto include/linux/skbuff.h:3862 [inline] eth_skb_pad include/linux/etherdevice.h:656 [inline] e1000_xmit_frame+0x2d99/0x5800 drivers/net/ethernet/intel/e1000/e1000_main.c:3128 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3806 [inline] dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3822 sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343 __dev_xmit_skb net/core/dev.c:4045 [inline] __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4621 dev_queue_xmit include/linux/netdevice.h:3313 [inline] llc_sap_action_send_test_c+0x268/0x320 net/llc/llc_s_ac.c:144 llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline] llc_sap_next_state net/llc/llc_sap.c:182 [inline] llc_sap_state_process+0x239/0x510 net/llc/llc_sap.c:209 llc_ui_sendmsg+0xd0d/0x14e0 net/llc/af_llc.c:993 sock_sendmsg_nosec net/socket.c:718 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21926 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: gso: fix ownership in __udp_gso_segmentIn __udp_gso_segment the skb destructor is removed before segmenting theskb but the socket reference is kept as-is. This is an issue if theoriginal skb is later orphaned as we can hit the following bug: kernel BUG at ./include/linux/skbuff.h:3312! (skb_orphan) RIP: 0010:ip_rcv_core+0x8b2/0xca0 Call Trace: ip_rcv+0xab/0x6e0 __netif_receive_skb_one_core+0x168/0x1b0 process_backlog+0x384/0x1100 __napi_poll.constprop.0+0xa1/0x370 net_rx_action+0x925/0xe50The above can happen following a sequence of events when usingOpenVSwitch, when an OVS_ACTION_ATTR_USERSPACE action precedes anOVS_ACTION_ATTR_OUTPUT action:1. OVS_ACTION_ATTR_USERSPACE is handled (in do_execute_actions): the skb goes through queue_gso_packets and then __udp_gso_segment, where its destructor is removed.2. The segments' data are copied and sent to userspace.3. OVS_ACTION_ATTR_OUTPUT is handled (in do_execute_actions) and the same original skb is sent to its path.4. If it later hits skb_orphan, we hit the bug.Fix this by also removing the reference to the socket in__udp_gso_segment.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21927 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix potential memory corruption in nvme_tcp_recv_pdu()nvme_tcp_recv_pdu() doesn't check the validity of the header length.When header digests are enabled, a target might send a packet with aninvalid header length (e.g. 255), causing nvme_tcp_verify_hdgst()to access memory outside the allocated area and cause memory corruptionsby overwriting it with the calculated digest.Fix this by rejecting packets with an unexpected header length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21928 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: intel-ish-hid: Fix use-after-free issue in ishtp_hid_remove()The system can experience a random crash a few minutes after the driver isremoved. This issue occurs due to improper handling of memory freeing inthe ishtp_hid_remove() function.The function currently frees the `driver_data` directly within the loopthat destroys the HID devices, which can lead to accessing freed memory.Specifically, `hid_destroy_device()` uses `driver_data` when it calls`hid_ishtp_set_feature()` to power off the sensor, so freeing`driver_data` beforehand can result in accessing invalid memory.This patch resolves the issue by storing the `driver_data` in a temporaryvariable before calling `hid_destroy_device()`, and then freeing the`driver_data` after the device is destroyed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwpoison, memory_hotplug: lock folio before unmap hwpoisoned folioCommit b15c87263a69 ("hwpoison, memory_hotplug: allow hwpoisoned pages tobe offlined) add page poison checks in do_migrate_range in order to makeoffline hwpoisoned page possible by introducing isolate_lru_page andtry_to_unmap for hwpoisoned page. However folio lock must be held beforecalling try_to_unmap. Add it to fix this problem.Warning will be produced if folio is not locked during unmap: ------------[ cut here ]------------ kernel BUG at ./include/linux/swapops.h:400! Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP Modules linked in: CPU: 4 UID: 0 PID: 411 Comm: bash Tainted: G W 6.13.0-rc1-00016-g3c434c7ee82a-dirty #41 Tainted: [W]=WARN Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : try_to_unmap_one+0xb08/0xd3c lr : try_to_unmap_one+0x3dc/0xd3c Call trace: try_to_unmap_one+0xb08/0xd3c (P) try_to_unmap_one+0x3dc/0xd3c (L) rmap_walk_anon+0xdc/0x1f8 rmap_walk+0x3c/0x58 try_to_unmap+0x88/0x90 unmap_poisoned_folio+0x30/0xa8 do_migrate_range+0x4a0/0x568 offline_pages+0x5a4/0x670 memory_block_action+0x17c/0x374 memory_subsys_offline+0x3c/0x78 device_offline+0xa4/0xd0 state_store+0x8c/0xf0 dev_attr_store+0x18/0x2c sysfs_kf_write+0x44/0x54 kernfs_fop_write_iter+0x118/0x1a8 vfs_write+0x3a8/0x4bc ksys_write+0x6c/0xf8 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x44/0x100 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xd0 el0t_64_sync_handler+0xc8/0xcc el0t_64_sync+0x198/0x19c Code: f9407be0 b5fff320 d4210000 17ffff97 (d4210000) ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21934 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: fix an API misues when rio_add_net() failsrio_add_net() calls device_register() and fails when device_register()fails. Thus, put_device() should be used rather than kfree(). Add"mport->net = NULL;" to avoid a use after free issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21935 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rapidio: add check for rio_add_net() in rio_scan_alloc_net()The return value of rio_add_net() should be checked. If it fails,put_device() should be called to free the memory and give up the referenceinitialized in rio_add_net().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21941 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipe_ctx->plane_state in resource_build_scaling_paramsNull pointer dereference issue could occur when pipe_ctx->plane_stateis null. The fix adds a check to ensure 'pipe_ctx->plane_state' is notnull before accessing. This prevents a null pointer dereference.Found by code review.(cherry picked from commit 63e6a77ccf239337baa9b1e7787cde9fa0462092)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21948 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: appleir: Fix potential NULL dereference at raw event handleSyzkaller reports a NULL pointer dereference issue in input_event().BUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]BUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]BUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395Read of size 8 at addr 0000000000000028 by task syz-executor199/2949CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 kasan_report+0xd9/0x110 mm/kasan/report.c:602 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 instrument_atomic_read include/linux/instrumented.h:68 [inline] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] is_event_supported drivers/input/input.c:67 [inline] input_event+0x42/0xa0 drivers/input/input.c:395 input_report_key include/linux/input.h:439 [inline] key_down drivers/hid/hid-appleir.c:159 [inline] appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993 __run_hrtimer kernel/time/hrtimer.c:1739 [inline] __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handle_softirqs+0x206/0x8d0 kernel/softirq.c:561 __do_softirq kernel/softirq.c:595 [inline] invoke_softirq kernel/softirq.c:435 [inline] __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662 irq_exit_rcu+0x9/0x30 kernel/softirq.c:678 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185 add_timer+0x62/0x90 kernel/time/timer.c:1295 schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98 usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f This happens due to the malformed report items sent by the emulated devicewhich results in a report, that has no fields, being added to the report list.Due to this appleir_input_configured() is never called, hidinput_connect()fails which results in the HID_CLAIMED_INPUT flag is not being set. However,it does not make appleir_probe() fail and lets the event callback to becalled without the associated input device.Thus, add a check for the HID_CLAIMED_INPUT flag and leave the event hookearly if the driver didn't claim any input_dev for some reason. Moreover,some other hid drivers accessing input_dev in their event callbacks do havesimilar checks, too.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21950 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drivers: virt: acrn: hsm: Use kzalloc to avoid info leak in pmcmd_ioctlIn the "pmcmd_ioctl" function, three memory objects allocated bykmalloc are initialized by "hcall_get_cpu_state", which are thencopied to user space. The initializer is indeed implemented in"acrn_hypercall2" (arch/x86/include/asm/acrn.h). There is a risk ofinformation leakage due to uninitialized bytes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21951 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: pci_generic: Use pci_try_reset_function() to avoid deadlockThere are multiple places from where the recovery work gets scheduledasynchronously. Also, there are multiple places where the caller waitssynchronously for the recovery to be completed. One such place is duringthe PM shutdown() callback.If the device is not alive during recovery_work, it will try to reset thedevice using pci_reset_function(). This function internally will take thedevice_lock() first before resetting the device. By this time, if the lockhas already been acquired, then recovery_work will get stalled whilewaiting for the lock. And if the lock was already acquired by the callerwhich waits for the recovery_work to be completed, it will lead todeadlock.This is what happened on the X1E80100 CRD device when the device diedbefore shutdown() callback. Driver core calls the driver's shutdown()callback while holding the device_lock() leading to deadlock.And this deadlock scenario can occur on other paths as well, like duringthe PM suspend() callback, where the driver core would hold thedevice_lock() before calling driver's suspend() callback. And if therecovery_work was already started, it could lead to deadlock. This is alsoobserved on the X1E80100 CRD.So to fix both issues, use pci_try_reset_function() in recovery_work. Thisfunction first checks for the availability of the device_lock() beforetrying to reset the device. If the lock is available, it will acquire itand reset the device. Otherwise, it will return -EAGAIN. If that happens,recovery_work will fail with the error message "Recovery failed" as notmuch could be done.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21953 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: mana: cleanup mana struct after debugfs_remove()When on a MANA VM hibernation is triggered, as part of hibernate_snapshot(),mana_gd_suspend() and mana_gd_resume() are called. If during thismana_gd_resume(), a failure occurs with HWC creation, mana_port_debugfspointer does not get reinitialized and ends up pointing to older,cleaned-up dentry.Further in the hibernation path, as part of power_down(), mana_gd_shutdown()is triggered. This call, unaware of the failures in resume, tries to cleanupthe already cleaned up mana_port_debugfs value and hits the following bug:[ 191.359296] mana 7870:00:00.0: Shutdown was called[ 191.359918] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 191.360584] #PF: supervisor write access in kernel mode[ 191.361125] #PF: error_code(0x0002) - not-present page[ 191.361727] PGD 1080ea067 P4D 0[ 191.362172] Oops: Oops: 0002 [#1] SMP NOPTI[ 191.362606] CPU: 11 UID: 0 PID: 1674 Comm: bash Not tainted 6.14.0-rc5+ #2[ 191.363292] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 11/21/2024[ 191.364124] RIP: 0010:down_write+0x19/0x50[ 191.364537] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 53 48 89 fb e8 de cd ff ff 31 c0 ba 01 00 00 00 48 0f b1 13 75 16 65 48 8b 05 88 24 4c 6a 48 89 43 08 48 8b 5d[ 191.365867] RSP: 0000:ff45fbe0c1c037b8 EFLAGS: 00010246[ 191.366350] RAX: 0000000000000000 RBX: 0000000000000098 RCX: ffffff8100000000[ 191.366951] RDX: 0000000000000001 RSI: 0000000000000064 RDI: 0000000000000098[ 191.367600] RBP: ff45fbe0c1c037c0 R08: 0000000000000000 R09: 0000000000000001[ 191.368225] R10: ff45fbe0d2b01000 R11: 0000000000000008 R12: 0000000000000000[ 191.368874] R13: 000000000000000b R14: ff43dc27509d67c0 R15: 0000000000000020[ 191.369549] FS: 00007dbc5001e740(0000) GS:ff43dc663f380000(0000) knlGS:0000000000000000[ 191.370213] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 191.370830] CR2: 0000000000000098 CR3: 0000000168e8e002 CR4: 0000000000b73ef0[ 191.371557] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 191.372192] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 191.372906] Call Trace:[ 191.373262] [ 191.373621] ? show_regs+0x64/0x70[ 191.374040] ? __die+0x24/0x70[ 191.374468] ? page_fault_oops+0x290/0x5b0[ 191.374875] ? do_user_addr_fault+0x448/0x800[ 191.375357] ? exc_page_fault+0x7a/0x160[ 191.375971] ? asm_exc_page_fault+0x27/0x30[ 191.376416] ? down_write+0x19/0x50[ 191.376832] ? down_write+0x12/0x50[ 191.377232] simple_recursive_removal+0x4a/0x2a0[ 191.377679] ? __pfx_remove_one+0x10/0x10[ 191.378088] debugfs_remove+0x44/0x70[ 191.378530] mana_detach+0x17c/0x4f0[ 191.378950] ? __flush_work+0x1e2/0x3b0[ 191.379362] ? __cond_resched+0x1a/0x50[ 191.379787] mana_remove+0xf2/0x1a0[ 191.380193] mana_gd_shutdown+0x3b/0x70[ 191.380642] pci_device_shutdown+0x3a/0x80[ 191.381063] device_shutdown+0x13e/0x230[ 191.381480] kernel_power_off+0x35/0x80[ 191.381890] hibernate+0x3c6/0x470[ 191.382312] state_store+0xcb/0xd0[ 191.382734] kobj_attr_store+0x12/0x30[ 191.383211] sysfs_kf_write+0x3e/0x50[ 191.383640] kernfs_fop_write_iter+0x140/0x1d0[ 191.384106] vfs_write+0x271/0x440[ 191.384521] ksys_write+0x72/0xf0[ 191.384924] __x64_sys_write+0x19/0x20[ 191.385313] x64_sys_call+0x2b0/0x20b0[ 191.385736] do_syscall_64+0x79/0x150[ 191.386146] ? __mod_memcg_lruvec_state+0xe7/0x240[ 191.386676] ? __lruvec_stat_mod_folio+0x79/0xb0[ 191.387124] ? __pfx_lru_add+0x10/0x10[ 191.387515] ? queued_spin_unlock+0x9/0x10[ 191.387937] ? do_anonymous_page+0x33c/0xa00[ 191.388374] ? __handle_mm_fault+0xcf3/0x1210[ 191.388805] ? __count_memcg_events+0xbe/0x180[ 191.389235] ? handle_mm_fault+0xae/0x300[ 19---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21963 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acdirmax mount optionUser-provided mount parameter acdirmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21964 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: Fix integer overflow while processing acregmax mount optionUser-provided mount parameter acregmax of type u32 is intended to havean upper limit, but before it is validated, the value is converted fromseconds to jiffies which can lead to an integer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix slab-use-after-free on hdcp_work[Why]A slab-use-after-free is reported when HDCP is destroyed but theproperty_validate_dwork queue is still running.[How]Cancel the delayed work when destroying workqueue.(cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmdAfter the hci sync command releases l2cap_conn, the hci receive data workqueue references the released l2cap_conn when sending to the upper layer.Add hci dev lock to the hci receive data work queue to synchronize the two.[1]BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954Read of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837CPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: hci1 hci_rx_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0x169/0x550 mm/kasan/report.c:489 kasan_report+0x143/0x180 mm/kasan/report.c:602 l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline] l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline] l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817 hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline] hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 5837: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329 kmalloc_noprof include/linux/slab.h:901 [inline] kzalloc_noprof include/linux/slab.h:1037 [inline] l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860 l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726 hci_event_func net/bluetooth/hci_event.c:7473 [inline] hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525 hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Freed by task 54: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:233 [inline] slab_free_hook mm/slub.c:2353 [inline] slab_free mm/slub.c:4613 [inline] kfree+0x196/0x430 mm/slub.c:4761 l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235 hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline] hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266 hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603 hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Bridge, fix the crash caused by LAG state checkWhen removing LAG device from bridge, NETDEV_CHANGEUPPER event istriggered. Driver finds the lower devices (PFs) to flush all theoffloaded entries. And mlx5_lag_is_shared_fdb is checked, it returnsfalse if one of PF is unloaded. In such case,mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead ofthe alive PF, and the flush is skipped.Besides, the bridge fdb entry's lastuse is updated in mlx5 bridgeevent handler. But this SWITCHDEV_FDB_ADD_TO_BRIDGE event can beignored in this case because the upper interface for bond is deleted,and the entry will never be aged because lastuse is never updated.To make things worse, as the entry is alive, mlx5 bridge workqueuekeeps sending that event, which is then handled by kernel bridgenotifier. It causes the following crash when accessing the passed bondnetdev which is already destroyed.To fix this issue, remove such checks. LAG state is already checked incommit 15f8f168952f ("net/mlx5: Bridge, verify LAG state when addingbond to bridge"), driver still need to skip offload if LAG becomesinvalid state after initialization. Oops: stack segment: 0000 [#1] SMP CPU: 3 UID: 0 PID: 23695 Comm: kworker/u40:3 Tainted: G OE 6.11.0_mlnx #1 Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_bridge_wq mlx5_esw_bridge_update_work [mlx5_core] RIP: 0010:br_switchdev_event+0x2c/0x110 [bridge] Code: 44 00 00 48 8b 02 48 f7 00 00 02 00 00 74 69 41 54 55 53 48 83 ec 08 48 8b a8 08 01 00 00 48 85 ed 74 4a 48 83 fe 02 48 89 d3 <4c> 8b 65 00 74 23 76 49 48 83 fe 05 74 7e 48 83 fe 06 75 2f 0f b7 RSP: 0018:ffffc900092cfda0 EFLAGS: 00010297 RAX: ffff888123bfe000 RBX: ffffc900092cfe08 RCX: 00000000ffffffff RDX: ffffc900092cfe08 RSI: 0000000000000001 RDI: ffffffffa0c585f0 RBP: 6669746f6e690a30 R08: 0000000000000000 R09: ffff888123ae92c8 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888123ae9c60 R13: 0000000000000001 R14: ffffc900092cfe08 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f15914c8734 CR3: 0000000002830005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __die_body+0x1a/0x60 ? die+0x38/0x60 ? do_trap+0x10b/0x120 ? do_error_trap+0x64/0xa0 ? exc_stack_segment+0x33/0x50 ? asm_exc_stack_segment+0x22/0x30 ? br_switchdev_event+0x2c/0x110 [bridge] ? sched_balance_newidle.isra.149+0x248/0x390 notifier_call_chain+0x4b/0xa0 atomic_notifier_call_chain+0x16/0x20 mlx5_esw_bridge_update+0xec/0x170 [mlx5_core] mlx5_esw_bridge_update_work+0x19/0x40 [mlx5_core] process_scheduled_works+0x81/0x390 worker_thread+0x106/0x250 ? bh_worker+0x110/0x110 kthread+0xb7/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21975 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: handle errors in mlx5_chains_create_table()In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns()and mlx5_get_flow_namespace() must be checked to prevent NULL pointerdereferences. If either function fails, the function should log errormessage with mlx5_core_warn() and return error pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21978 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/hyperv: Fix address space leak when Hyper-V DRM device is removedWhen a Hyper-V DRM device is probed, the driver allocates MMIO space forthe vram, and maps it cacheable. If the device removed, or in the errorpath for device probing, the MMIO space is released but no unmap is done.Consequently the kernel address space for the mapping is leaked.Fix this by adding iounmap() calls in the device removal path, and in theerror path during device probing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched: address a potential NULL pointer dereference in the GRED scheduler.If kzalloc in gred_init returns a NULL pointer, the code follows theerror handling path, invoking gred_destroy. This, in turn, callsgred_offload, where memset could receive a NULL pointer as input,potentially leading to a kernel crash.When table->opt is NULL in gred_init(), gred_change_table_def()is not called yet, so it is not necessary to call ->ndo_setup_tc()in gred_offload().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21991 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/microcode/AMD: Fix out-of-bounds on systems with CPU-less NUMA nodesCurrently, load_microcode_amd() iterates over all NUMA nodes, retrieves theirCPU masks and unconditionally accesses per-CPU data for the first CPU of eachmask.According to Documentation/admin-guide/mm/numaperf.rst: "Some memory may share the same node as a CPU, and others are provided as memory only nodes."Therefore, some node CPU masks may be empty and wouldn't have a "first CPU".On a machine with far memory (and therefore CPU-less NUMA nodes):- cpumask_of_node(nid) is 0- cpumask_first(0) is CONFIG_NR_CPUS- cpu_data(CONFIG_NR_CPUS) accesses the cpu_info per-CPU array at an index that is 1 out of boundsThis does not have any security implications since flashing microcode isa privileged operation but I believe this has reliability implications bypotentially corrupting memory while flashing a microcode update.When booting with CONFIG_UBSAN_BOUNDS=y on an AMD machine that flashesa microcode update. I get the following splat: UBSAN: array-index-out-of-bounds in arch/x86/kernel/cpu/microcode/amd.c:X:Y index 512 is out of range for type 'unsigned long[512]' [...] Call Trace: dump_stack __ubsan_handle_out_of_bounds load_microcode_amd request_microcode_amd reload_store kernfs_fop_write_iter vfs_write ksys_write do_syscall_64 entry_SYSCALL_64_after_hwframeChange the loop to go over only NUMA nodes which have CPUs before determiningwhether the first CPU on the respective node needs microcode update. [ bp: Massage commit message, fix typo. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: ignore non-functional sensor in HP 5MP CameraThe HP 5MP Camera (USB ID 0408:5473) reports a HID sensor interface thatis not actually implemented. Attempting to access this non-functionalsensor via iio_info causes system hangs as runtime PM tries to wake upan unresponsive sensor. [453] hid-sensor-hub 0003:0408:5473.0003: Report latency attributes: ffffffff:ffffffff [453] hid-sensor-hub 0003:0408:5473.0003: common attributes: 5:1, 2:1, 3:1 ffffffff:ffffffffAdd this device to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21993 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iscsi_ibft: Fix UBSAN shift-out-of-bounds warning in ibft_attr_show_nic()When performing an iSCSI boot using IPv6, iscsistart still reads the/sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefixlength is 64, this causes the shift exponent to become negative,triggering a UBSAN warning. As the concept of a subnet mask does notapply to IPv6, the value is set to ~0 to suppress the warning message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix uninitialized size issue in radeon_vce_cs_parse()On the off chance that command stream passed from userspace viaioctl() call to radeon_vce_cs_parse() is weirdly crafted andfirst command to execute is to encode (case 0x03000001), the functionin question will attempt to call radeon_vce_cs_reloc() with sizeargument that has not been properly initialized. Specifically, 'size'will point to 'tmp' variable before the latter had a chance to beassigned any value.Play it safe and init 'tmp' with 0, thus ensuring thatradeon_vce_cs_reloc() will catch an early error in cases like these.Found by Linux Verification Center (linuxtesting.org) with staticanalysis tool SVACE.(cherry picked from commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22003 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: ucan: fix out of bound read in strscpy() sourceCommit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()")unintentionally introduced a one byte out of bound read on strscpy()'ssource argument (which is kind of ironic knowing that strscpy() is meantto be a more secure alternative :)).Let's consider below buffers: dest[len + 1]; /* will be NUL terminated */ src[len]; /* may not be NUL terminated */When doing: strncpy(dest, src, len); dest[len] = '\0';strncpy() will read up to len bytes from src.On the other hand: strscpy(dest, src, len + 1);will read up to len + 1 bytes from src, that is to say, an out of boundread of one byte will occur on src if it is not NUL terminated. Notethat the src[len] byte is never copied, but strscpy() still needs toread it to check whether a truncation occurred or not.This exact pattern happened in ucan.The root cause is that the source is not NUL terminated. Instead ofdoing a copy in a local buffer, directly NUL terminate it as soon asusb_control_msg() returns. With this, the local firmware_str[] variablecan be removed.On top of this do a couple refactors: - ucan_ctl_payload->raw is only used for the firmware string, so rename it to ucan_ctl_payload->fw_str and change its type from u8 to char. - ucan_device_request_in() is only used to retrieve the firmware string, so rename it to ucan_get_fw_str() and refactor it to make it directly handle all the string termination logic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22005 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: Fix memleak of nhc_pcpu_rth_output in fib_check_nh_v6_gw().fib_check_nh_v6_gw() expects that fib6_nh_init() cleans up everythingwhen it fails.Commit 7dd73168e273 ("ipv6: Always allocate pcpu memory in a fib6_nh")moved fib_nh_common_init() before alloc_percpu_gfp() within fib6_nh_init()but forgot to add cleanup for fib6_nh->nh_common.nhc_pcpu_rth_output incase it fails to allocate fib6_nh->rt6i_pcpu, resulting in memleak.Let's call fib_nh_common_release() and clear nhc_pcpu_rth_output in theerror path.Note that we can remove the fib6_nh_release() call in nh_create_ipv6()later in net-next.git.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22007 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix error code in chan_alloc_skb_cb()The chan_alloc_skb_cb() function is supposed to return error pointers onerror. Returning NULL will lead to a NULL dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: check that dummy regulator has been probed before using itDue to asynchronous driver probing there is a chance that the dummyregulator hasn't already been probed when first accessing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix soft lockup during bt pages loopDriver runs a for-loop when allocating bt pages and mapping them withbuffer pages. When a large buffer (e.g. MR over 100GB) is being allocated,it may require a considerable loop count. This will lead to soft lockup: watchdog: BUG: soft lockup - CPU#27 stuck for 22s! ... Call trace: hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2] hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2] hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2] alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2] hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x118/0x290 watchdog: BUG: soft lockup - CPU#35 stuck for 23s! ... Call trace: hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2] mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2] hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2] alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2] hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2] ib_uverbs_reg_mr+0x120/0x2bcAdd a cond_resched() to fix soft lockup during these loops. In order notto affect the allocation performance of normal-size buffer, set the loopcount of a 100GB MR as the threshold to call cond_resched().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: Fix the potential deadlockWhen some client process A call pdr_add_lookup() to add the look up forthe service and does schedule locator work, later a process B got a newserver packet indicating locator is up and call pdr_locator_new_server()which eventually sets pdr->locator_init_complete to true which process Asees and takes list lock and queries domain list but it will timeout dueto deadlock as the response will queued to the same qmi->wq and it isordered workqueue and process B is not able to complete new serverrequest work due to deadlock on list lock.Fix it by removing the unnecessary list iteration as the list iterationis already being done inside locator work, so avoid it here and justcall schedule_work() here. Process A Process B process_scheduled_works()pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret);Timeout error log due to deadlock:" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110"Thanks to Bjorn and Johan for letting me know that this commit also fixesan audio regression when using the in-kernel pd-mapper as that makes iteasier to hit this race. [1]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22018 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Fix NULL pointer dereferenceWhen MPOA_cache_impos_rcvd() receives the msg, it can triggerNull Pointer Dereference Vulnerability if both entry andholding_time are NULL. Because there is only for the situationwhere entry is NULL and holding_time exists, it can be passedwhen both entry and holding_time are NULL. If these are NULL,the entry will be passd to eg_cache_put() as parameter andit is referenced by entry->use code in it.kasan log:[ 3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I[ 3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037][ 3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102[ 3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014[ 3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470[ 3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80[ 3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006[ 3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e[ 3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030[ 3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88[ 3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15[ 3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068[ 3.324185] FS: 000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000[ 3.325042] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0[ 3.326430] Call Trace:[ 3.326725] [ 3.326927] ? die_addr+0x3c/0xa0[ 3.327330] ? exc_general_protection+0x161/0x2a0[ 3.327662] ? asm_exc_general_protection+0x26/0x30[ 3.328214] ? vprintk_emit+0x15e/0x420[ 3.328543] ? eg_cache_remove_entry+0xa5/0x470[ 3.328910] ? eg_cache_remove_entry+0x9a/0x470[ 3.329294] ? __pfx_eg_cache_remove_entry+0x10/0x10[ 3.329664] ? console_unlock+0x107/0x1d0[ 3.329946] ? __pfx_console_unlock+0x10/0x10[ 3.330283] ? do_syscall_64+0xa6/0x1a0[ 3.330584] ? entry_SYSCALL_64_after_hwframe+0x47/0x7f[ 3.331090] ? __pfx_prb_read_valid+0x10/0x10[ 3.331395] ? down_trylock+0x52/0x80[ 3.331703] ? vprintk_emit+0x15e/0x420[ 3.331986] ? __pfx_vprintk_emit+0x10/0x10[ 3.332279] ? down_trylock+0x52/0x80[ 3.332527] ? _printk+0xbf/0x100[ 3.332762] ? __pfx__printk+0x10/0x10[ 3.333007] ? _raw_write_lock_irq+0x81/0xe0[ 3.333284] ? __pfx__raw_write_lock_irq+0x10/0x10[ 3.333614] msg_from_mpoad+0x1185/0x2750[ 3.333893] ? __build_skb_around+0x27b/0x3a0[ 3.334183] ? __pfx_msg_from_mpoad+0x10/0x10[ 3.334501] ? __alloc_skb+0x1c0/0x310[ 3.334809] ? __pfx___alloc_skb+0x10/0x10[ 3.335283] ? _raw_spin_lock+0xe0/0xe0[ 3.335632] ? finish_wait+0x8d/0x1e0[ 3.335975] vcc_sendmsg+0x684/0xba0[ 3.336250] ? __pfx_vcc_sendmsg+0x10/0x10[ 3.336587] ? __pfx_autoremove_wake_function+0x10/0x10[ 3.337056] ? fdget+0x176/0x3e0[ 3.337348] __sys_sendto+0x4a2/0x510[ 3.337663] ? __pfx___sys_sendto+0x10/0x10[ 3.337969] ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400[ 3.338364] ? sock_ioctl+0x1bb/0x5a0[ 3.338653] ? __rseq_handle_notify_resume+0x825/0xd20[ 3.339017] ? __pfx_sock_ioctl+0x10/0x10[ 3.339316] ? __pfx___rseq_handle_notify_resume+0x10/0x10[ 3.339727] ? selinux_file_ioctl+0xa4/0x260[ 3.340166] __x64_sys_sendto+0xe0/0x1c0[ 3.340526] ? syscall_exit_to_user_mode+0x123/0x140[ 3.340898] do_syscall_64+0xa6/0x1a0[ 3.341170] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 3.341533] RIP: 0033:0x44a380[ 3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00[ ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22028 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vimc: skip .s_stream() for stopped entitiesSyzbot reported [1] a warning prompted by a check in call_s_stream()that checks whether .s_stream() operation is warranted for unstartedor stopped subdevs.Add a simple fix in vimc_streamer_pipeline_terminate() ensuring thatentities skip a call to .s_stream() unless they have been previouslyproperly started.[1] Syzbot report:------------[ cut here ]------------WARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460Modules linked in:CPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0...Call Trace: vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62 vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline] vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203 vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256 vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789 vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348 vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline] vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118 __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122 video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463 v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f2b85c01b19...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22044 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:acpi: nfit: fix narrowing conversion in acpi_nfit_ctlSyzkaller has reported a warning in to_nfit_bus_uuid(): "only secondarybus families can be translated". This warning is emited if the argumentis equal to NVDIMM_BUS_FAMILY_NFIT == 0. Function acpi_nfit_ctl() firstverifies that a user-provided value call_pkg->nd_family of type u64 isnot equal to 0. Then the value is converted to int, and only after thatis compared to NVDIMM_BUS_FAMILY_MAX. This can lead to passing an invalidargument to acpi_nfit_ctl(), if call_pkg->nd_family is non-zero, whilethe lower 32 bits are zero.Furthermore, it is best to return EINVAL immediately upon seeing theinvalid user input. The WARNING is insufficient to prevent furtherundefined behavior based on other invalid user input.All checks of the input value should be applied to the original variablecall_pkg->nd_family.[iweiny: update commit message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ibmveth: make veth_pool_store stop hangingv2:- Created a single error handling unlock and exit in veth_pool_store- Greatly expanded commit message with previous explanatory-only textSummary: Use rtnl_mutex to synchronize veth_pool_store with itself,ibmveth_close and ibmveth_open, preventing multiple calls in a row tonapi_disable.Background: Two (or more) threads could call veth_pool_store throughwriting to /sys/devices/vio/30000002/pool*/*. You can do this easilywith a little shell script. This causes a hang.I configured LOCKDEP, compiled ibmveth.c with DEBUG, and built a newkernel. I ran this test again and saw: Setting pool0/active to 0 Setting pool1/active to 1 [ 73.911067][ T4365] ibmveth 30000002 eth0: close starting Setting pool1/active to 1 Setting pool1/active to 0 [ 73.911367][ T4366] ibmveth 30000002 eth0: close starting [ 73.916056][ T4365] ibmveth 30000002 eth0: close complete [ 73.916064][ T4365] ibmveth 30000002 eth0: open starting [ 110.808564][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 230.808495][ T712] systemd-journald[712]: Sent WATCHDOG=1 notification. [ 243.683786][ T123] INFO: task stress.sh:4365 blocked for more than 122 seconds. [ 243.683827][ T123] Not tainted 6.14.0-01103-g2df0c02dab82-dirty #8 [ 243.683833][ T123] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 243.683838][ T123] task:stress.sh state:D stack:28096 pid:4365 tgid:4365 ppid:4364 task_flags:0x400040 flags:0x00042000 [ 243.683852][ T123] Call Trace: [ 243.683857][ T123] [c00000000c38f690] [0000000000000001] 0x1 (unreliable) [ 243.683868][ T123] [c00000000c38f840] [c00000000001f908] __switch_to+0x318/0x4e0 [ 243.683878][ T123] [c00000000c38f8a0] [c000000001549a70] __schedule+0x500/0x12a0 [ 243.683888][ T123] [c00000000c38f9a0] [c00000000154a878] schedule+0x68/0x210 [ 243.683896][ T123] [c00000000c38f9d0] [c00000000154ac80] schedule_preempt_disabled+0x30/0x50 [ 243.683904][ T123] [c00000000c38fa00] [c00000000154dbb0] __mutex_lock+0x730/0x10f0 [ 243.683913][ T123] [c00000000c38fb10] [c000000001154d40] napi_enable+0x30/0x60 [ 243.683921][ T123] [c00000000c38fb40] [c000000000f4ae94] ibmveth_open+0x68/0x5dc [ 243.683928][ T123] [c00000000c38fbe0] [c000000000f4aa20] veth_pool_store+0x220/0x270 [ 243.683936][ T123] [c00000000c38fc70] [c000000000826278] sysfs_kf_write+0x68/0xb0 [ 243.683944][ T123] [c00000000c38fcb0] [c0000000008240b8] kernfs_fop_write_iter+0x198/0x2d0 [ 243.683951][ T123] [c00000000c38fd00] [c00000000071b9ac] vfs_write+0x34c/0x650 [ 243.683958][ T123] [c00000000c38fdc0] [c00000000071bea8] ksys_write+0x88/0x150 [ 243.683966][ T123] [c00000000c38fe10] [c0000000000317f4] system_call_exception+0x124/0x340 [ 243.683973][ T123] [c00000000c38fe50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec ... [ 243.684087][ T123] Showing all locks held in the system: [ 243.684095][ T123] 1 lock held by khungtaskd/123: [ 243.684099][ T123] #0: c00000000278e370 (rcu_read_lock){....}-{1:2}, at: debug_show_all_locks+0x50/0x248 [ 243.684114][ T123] 4 locks held by stress.sh/4365: [ 243.684119][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.684132][ T123] #1: c000000041aea888 (&of->mutex#2){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x154/0x2d0 [ 243.684143][ T123] #2: c0000000366fb9a8 (kn->active#64){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x160/0x2d0 [ 243.684155][ T123] #3: c000000035ff4cb8 (&dev->lock){+.+.}-{3:3}, at: napi_enable+0x30/0x60 [ 243.684166][ T123] 5 locks held by stress.sh/4366: [ 243.684170][ T123] #0: c00000003a4cd3f8 (sb_writers#3){.+.+}-{0:0}, at: ksys_write+0x88/0x150 [ 243.---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22062 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: add mutual exclusion in proc_sctp_do_udp_port()We must serialize calls to sctp_udp_sock_stop() and sctp_udp_sock_start()or risk a crash as syzbot reported:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000d: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]CPU: 1 UID: 0 PID: 6551 Comm: syz.1.44 Not tainted 6.14.0-syzkaller-g7f2ff7b62617 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025 RIP: 0010:kernel_sock_shutdown+0x47/0x70 net/socket.c:3653Call Trace: udp_tunnel_sock_release+0x68/0x80 net/ipv4/udp_tunnel_core.c:181 sctp_udp_sock_stop+0x71/0x160 net/sctp/protocol.c:930 proc_sctp_do_udp_port+0x264/0x450 net/sctp/sysctl.c:553 proc_sys_call_handler+0x3d0/0x5b0 fs/proc/proc_sysctl.c:601 iter_file_splice_write+0x91c/0x1150 fs/splice.c:738 do_splice_from fs/splice.c:935 [inline] direct_splice_actor+0x18f/0x6c0 fs/splice.c:1158 splice_direct_to_actor+0x342/0xa30 fs/splice.c:1102 do_splice_direct_actor fs/splice.c:1201 [inline] do_splice_direct+0x174/0x240 fs/splice.c:1227 do_sendfile+0xafd/0xe50 fs/read_write.c:1368 __do_sys_sendfile64 fs/read_write.c:1429 [inline] __se_sys_sendfile64 fs/read_write.c:1415 [inline] __x64_sys_sendfile64+0x1d8/0x220 fs/read_write.c:1415 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: imx-card: Add NULL check in imx_card_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,imx_card_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spufs: fix gang directory lifetimesprior to "[POWERPC] spufs: Fix gang destroy leaks" we used to havea problem with gang lifetimes - creation of a gang returns openedgang directory, which normally gets removed when that gets closed,but if somebody has created a context belonging to that gang andkept it alive until the gang got closed, removal failed and weended up with a leak.Unfortunately, it had been fixed the wrong way. Dentry of gangdirectory was no longer pinned, and rmdir on close was gone.One problem was that failure of open kept calling simple_rmdir()as cleanup, which meant an unbalanced dput(). Another bug wasin the success case - gang creation incremented link count onroot directory, but that was no longer undone when gang gotdestroyed.Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->i_rwsemof gang directory inode. * having it set to 1 at creation time, droppedin both spufs_dir_close() and spufs_gang_close() and bumpedin spufs_create_context(), provided that it's not 0. * using simple_recursive_removal() to take the gangdirectory out when counter reaches zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Allocate vfinfo size for VF GUIDs when supportedCommit 30aad41721e0 ("net/core: Add support for getting VF GUIDs")added support for getting VF port and node GUIDs in netlink ifinfomessages, but their size was not taken into consideration in thefunction that allocates the netlink message, causing the followingwarning when a netlink message is filled with many VF port and nodeGUIDs: # echo 64 > /sys/bus/pci/devices/0000\:08\:00.0/sriov_numvfs # ip link show dev ib0 RTNETLINK answers: Message too long Cannot send link get request: Message too longKernel warning: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 1930 at net/core/rtnetlink.c:4151 rtnl_getlink+0x586/0x5a0 Modules linked in: xt_conntrack xt_MASQUERADE nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay mlx5_ib macsec mlx5_core tls rpcrdma rdma_ucm ib_uverbs ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm iw_cm ib_ipoib fuse ib_cm ib_core CPU: 2 UID: 0 PID: 1930 Comm: ip Not tainted 6.14.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rtnl_getlink+0x586/0x5a0 Code: cb 82 e8 3d af 0a 00 4d 85 ff 0f 84 08 ff ff ff 4c 89 ff 41 be ea ff ff ff e8 66 63 5b ff 49 c7 07 80 4f cb 82 e9 36 fc ff ff <0f> 0b e9 16 fe ff ff e8 de a0 56 00 66 66 2e 0f 1f 84 00 00 00 00 RSP: 0018:ffff888113557348 EFLAGS: 00010246 RAX: 00000000ffffffa6 RBX: ffff88817e87aa34 RCX: dffffc0000000000 RDX: 0000000000000003 RSI: 0000000000000000 RDI: ffff88817e87afb8 RBP: 0000000000000009 R08: ffffffff821f44aa R09: 0000000000000000 R10: ffff8881260f79a8 R11: ffff88817e87af00 R12: ffff88817e87aa00 R13: ffffffff8563d300 R14: 00000000ffffffa6 R15: 00000000ffffffff FS: 00007f63a5dbf280(0000) GS:ffff88881ee00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f63a5ba4493 CR3: 00000001700fe002 CR4: 0000000000772eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? __warn+0xa5/0x230 ? rtnl_getlink+0x586/0x5a0 ? report_bug+0x22d/0x240 ? handle_bug+0x53/0xa0 ? exc_invalid_op+0x14/0x50 ? asm_exc_invalid_op+0x16/0x20 ? skb_trim+0x6a/0x80 ? rtnl_getlink+0x586/0x5a0 ? __pfx_rtnl_getlink+0x10/0x10 ? rtnetlink_rcv_msg+0x1e5/0x860 ? __pfx___mutex_lock+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx_lock_acquire+0x10/0x10 ? stack_trace_save+0x90/0xd0 ? filter_irq_stacks+0x1d/0x70 ? kasan_save_stack+0x30/0x40 ? kasan_save_stack+0x20/0x40 ? kasan_save_track+0x10/0x30 rtnetlink_rcv_msg+0x21c/0x860 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? arch_stack_walk+0x9e/0xf0 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 ? rcu_is_watching+0x34/0x60 netlink_rcv_skb+0xe0/0x210 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 ? __pfx_netlink_rcv_skb+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? __pfx___netlink_lookup+0x10/0x10 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0xfd/0x290 ? rcu_is_watching+0x34/0x60 ? lock_release+0x62/0x200 ? netlink_deliver_tap+0x95/0x290 netlink_unicast+0x31f/0x480 ? __pfx_netlink_unicast+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? lock_acquire+0xd5/0x410 netlink_sendmsg+0x369/0x660 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ? import_ubuf+0xb9/0xf0 ? __import_iovec+0x254/0x2b0 ? lock_release+0x62/0x200 ? __pfx_netlink_sendmsg+0x10/0x10 ____sys_sendmsg+0x559/0x5a0 ? __pfx_____sys_sendmsg+0x10/0x10 ? __pfx_copy_msghdr_from_user+0x10/0x10 ? rcu_is_watching+0x34/0x60 ? do_read_fault+0x213/0x4a0 ? rcu_is_watching+0x34/0x60 ___sys_sendmsg+0xe4/0x150 ? __pfx____sys_sendmsg+0x10/0x10 ? do_fault+0x2cc/0x6f0 ? handle_pte_fault+0x2e3/0x3d0 ? __pfx_handle_pte_fault+0x10/0x10---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "smb: client: fix TCP timers deadlock after rmmod"This reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.Commit e9f2517a3e18 ("smb: client: fix TCP timers deadlock afterrmmod") is intended to fix a null-ptr-deref in LOCKDEP, which ismentioned as CVE-2024-54680, but is actually did not fix anything;The issue can be reproduced on top of it. [0]Also, it reverted the change by commit ef7134c7fc48 ("smb: client:Fix use-after-free of network namespace.") and introduced a realissue by reviving the kernel TCP socket.When a reconnect happens for a CIFS connection, the socket statetransitions to FIN_WAIT_1. Then, inet_csk_clear_xmit_timers_sync()in tcp_close() stops all timers for the socket.If an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1forever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.Usually, FIN can be retransmitted by the peer, but if the peer abortsthe connection, the issue comes into reality.I warned about this privately by pointing out the exact report [1],but the bogus fix was finally merged.So, we should not stop the timers to finally kill the connection onour side in that case, meaning we must not use a kernel socket forTCP whose sk->sk_net_refcnt is 0.The kernel socket does not have a reference to its netns to make itpossible to tear down netns without cleaning up every resource in it.For example, tunnel devices use a UDP socket internally, but we candestroy netns without removing such devices and let it completeduring exit. Otherwise, netns would be leaked when the last applicationdied.However, this is problematic for TCP sockets because TCP has timers toclose the connection gracefully even after the socket is close()d. Thelifetime of the socket and its netns is different from the lifetime ofthe underlying connection.If the socket user does not maintain the netns lifetime, the timer couldbe fired after the socket is close()d and its netns is freed up, resultingin use-after-free.Actually, we have seen so many similar issues and converted such socketsto have a reference to netns.That's why I converted the CIFS client socket to have a reference tonetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scopeof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and rightfix**.Regarding the LOCKDEP issue, we can prevent the module unload bybumping the module refcount when switching the LOCKDDEP key insock_lock_init_class_and_name(). [2]For a while, let's revert the bogus fix.Note that now we can use sk_net_refcnt_upgrade() for the socketconversion, but I'll do so later separately to make backport easy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost-scsi: Fix handling of multiple calls to vhost_scsi_set_endpointIf vhost_scsi_set_endpoint is called multiple times without avhost_scsi_clear_endpoint between them, we can hit multiple bugsfound by Haoran Zhang:1. Use-after-free when no tpgs are found:This fixes a use after free that occurs when vhost_scsi_set_endpoint iscalled more than once and calls after the first call do not find anytpgs to add to the vs_tpg. When vhost_scsi_set_endpoint first findstpgs to add to the vs_tpg array match=true, so we will do:vhost_vq_set_backend(vq, vs_tpg);...kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If vhost_scsi_set_endpoint is called again and no tpgs are foundmatch=false so we skip the vhost_vq_set_backend call leaving thepointer to the vs_tpg we then free via:kfree(vs->vs_tpg);vs->vs_tpg = vs_tpg;If a scsi request is then sent we do:vhost_scsi_handle_vq -> vhost_scsi_get_req -> vhost_vq_get_backendwhich sees the vs_tpg we just did a kfree on.2. Tpg dir removal hang:This patch fixes an issue where we cannot remove a LIO/target layertpg (and structs above it like the target) dir due to the refcountdropping to -1.The problem is that if vhost_scsi_set_endpoint detects a tpg is alreadyin the vs->vs_tpg array or if the tpg has been removed sotarget_depend_item fails, the undepend goto handler will dotarget_undepend_item on all tpgs in the vs_tpg array dropping theirrefcount to 0. At this time vs_tpg contains both the tpgs we have addedin the current vhost_scsi_set_endpoint call as well as tpgs we added inprevious calls which are also in vs->vs_tpg.Later, when vhost_scsi_clear_endpoint runs it will dotarget_undepend_item on all the tpgs in the vs->vs_tpg which will droptheir refcount to -1. Userspace will then not be able to remove the tpgand will hang when it tries to do rmdir on the tpg dir.3. Tpg leak:This fixes a bug where we can leak tpgs and cause them to beun-removable because the target name is overwritten whenvhost_scsi_set_endpoint is called multiple times but with differenttarget names.The bug occurs if a user has called VHOST_SCSI_SET_ENDPOINT and setupa vhost-scsi device to target/tpg mapping, then callsVHOST_SCSI_SET_ENDPOINT again with a new target name that has tpgs wehaven't seen before (target1 has tpg1 but target2 has tpg2). When thishappens we don't teardown the old target tpg mapping and just overwritethe target name and the vs->vs_tpg array. Later when we dovhost_scsi_clear_endpoint, we are passed in either target1 or target2'sname and we will only match that target's tpgs when we loop over thevs->vs_tpg. We will then return from the function without doingtarget_undepend_item on the tpgs.Because of all these bugs, it looks like being able to callvhost_scsi_set_endpoint multiple times was never supported. The majoruser, QEMU, already has checks to prevent this use case. So to fix theissues, this patch prevents vhost_scsi_set_endpoint from being calledif it's already successfully added tpgs. To add, remove or change thetpg config or target name, you must do a vhost_scsi_clear_endpointfirst.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22086 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix mlx5_poll_one() cur_qp update flowWhen cur_qp isn't NULL, in order to avoid fetching the QP fromthe radix tree again we check if the next cqe QP is identical tothe one we already have.The bug however is that we are checking if the QP is identical bychecking the QP number inside the CQE against the QP number inside themlx5_ib_qp, but that's wrong since the QP number from the CQE is fromFW so it should be matched against mlx5_core_qp which is our FW QPnumber.Otherwise we could use the wrong QP when handling a CQE which couldcause the kernel trace below.This issue is mainly noticeable over QPs 0 & 1, since for now they arethe only QPs in our driver whereas the QP number inside mlx5_ib_qpdoesn't match the QP number inside mlx5_core_qp.BUG: kernel NULL pointer dereference, address: 0000000000000012 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP CPU: 0 UID: 0 PID: 7927 Comm: kworker/u62:1 Not tainted 6.14.0-rc3+ #189 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] Code: 03 00 00 8d 58 ff 21 cb 66 39 d3 74 39 48 c7 c7 3c 89 6e a0 0f b7 db e8 b7 d2 b3 e0 49 8b 86 60 03 00 00 48 c7 c7 4a 89 6e a0 <0f> b7 5c 98 02 e8 9f d2 b3 e0 41 0f b7 86 78 03 00 00 83 e8 01 21 RSP: 0018:ffff88810511bd60 EFLAGS: 00010046 RAX: 0000000000000010 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff88885fa1b3c0 RDI: ffffffffa06e894a RBP: 00000000000000b0 R08: 0000000000000000 R09: ffff88810511bc10 R10: 0000000000000001 R11: 0000000000000001 R12: ffff88810d593000 R13: ffff88810e579108 R14: ffff888105146000 R15: 00000000000000b0 FS: 0000000000000000(0000) GS:ffff88885fa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000012 CR3: 00000001077e6001 CR4: 0000000000370eb0 Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x130 ? asm_exc_page_fault+0x22/0x30 ? mlx5_ib_poll_cq+0x4c7/0xd90 [mlx5_ib] __ib_process_cq+0x5a/0x150 [ib_core] ib_cq_poll_work+0x31/0x90 [ib_core] process_one_work+0x169/0x320 worker_thread+0x288/0x3a0 ? work_busy+0xb0/0xb0 kthread+0xd7/0x1f0 ? kthreads_online_cpu+0x130/0x130 ? kthreads_online_cpu+0x130/0x130 ret_from_fork+0x2d/0x50 ? kthreads_online_cpu+0x130/0x130 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22090 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: Fix VM_PAT handling when fork() fails in copy_page_range()If track_pfn_copy() fails, we already added the dst VMA to the mapletree. As fork() fails, we'll cleanup the maple tree, and stumble overthe dst VMA for which we neither performed any reservation nor copiedany page tables.Consequently untrack_pfn() will see VM_PAT and try obtaining thePAT information from the page table -- which fails because the pagetable was not copied.The easiest fix would be to simply clear the VM_PAT flag of the dst VMAif track_pfn_copy() fails. However, the whole thing is about "simply"clearing the VM_PAT flag is shaky as well: if we passed track_pfn_copy()and performed a reservation, but copying the page tables fails, we'llsimply clear the VM_PAT flag, not properly undoing the reservation ...which is also wrong.So let's fix it properly: set the VM_PAT flag only if the reservationsucceeded (leaving it clear initially), and undo the reservation ifanything goes wrong while copying the page tables: clearing the VM_PATflag after undoing the reservation.Note that any copied page table entries will get zapped when the VMA willget removed later, after copy_page_range() succeeded; as VM_PAT is not setthen, we won't try cleaning VM_PAT up once more and untrack_pfn() will behappy. Note that leaving these page tables in place without a reservationis not a problem, as we are aborting fork(); this process will never run.A reproducer can trigger this usually at the first try: https://gitlab.com/davidhildenbrand/scratchspace/-/raw/main/reproducers/pat_fork.c WARNING: CPU: 26 PID: 11650 at arch/x86/mm/pat/memtype.c:983 get_pat_info+0xf6/0x110 Modules linked in: ... CPU: 26 UID: 0 PID: 11650 Comm: repro3 Not tainted 6.12.0-rc5+ #92 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:get_pat_info+0xf6/0x110 ... Call Trace: ... untrack_pfn+0x52/0x110 unmap_single_vma+0xa6/0xe0 unmap_vmas+0x105/0x1f0 exit_mmap+0xf6/0x460 __mmput+0x4b/0x120 copy_process+0x1bf6/0x2aa0 kernel_clone+0xab/0x440 __do_sys_clone+0x66/0x90 do_syscall_64+0x95/0x180Likely this case was missed in: d155df53f310 ("x86/mm/pat: clear VM_PAT if copy_p4d_range failed")... and instead of undoing the reservation we simply cleared the VM_PAT flag.Keep the documentation of these functions in include/linux/pgtable.h,one place is more than sufficient -- we should clean that up for the otherfunctions like track_pfn_remap/untrack_pfn separately.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Remove broken autobindBinding AX25 socket by using the autobind feature leads to memory leaksin ax25_connect() and also refcount leaks in ax25_release(). Memoryleak was detected with kmemleak:================================================================unreferenced object 0xffff8880253cd680 (size 96):backtrace:__kmalloc_node_track_caller_noprof (./include/linux/kmemleak.h:43)kmemdup_noprof (mm/util.c:136)ax25_rt_autobind (net/ax25/ax25_route.c:428)ax25_connect (net/ax25/af_ax25.c:1282)__sys_connect_file (net/socket.c:2045)__sys_connect (net/socket.c:2064)__x64_sys_connect (net/socket.c:2067)do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)================================================================When socket is bound, refcounts must be incremented the way it is donein ax25_bind() and ax25_setsockopt() (SO_BINDTODEVICE). In case ofautobind, the refcounts are not incremented.This bug leads to the following issue reported by Syzkaller:================================================================ax25_connect(): syz-executor318 uses autobind, please contact jreuter@yaina.de------------[ cut here ]------------refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 0 PID: 5317 at lib/refcount.c:31 refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31Modules linked in:CPU: 0 UID: 0 PID: 5317 Comm: syz-executor318 Not tainted 6.14.0-rc4-syzkaller-00278-gece144f151ac #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:refcount_warn_saturate+0xfa/0x1d0 lib/refcount.c:31...Call Trace: __refcount_dec include/linux/refcount.h:336 [inline] refcount_dec include/linux/refcount.h:351 [inline] ref_tracker_free+0x6af/0x7e0 lib/ref_tracker.c:236 netdev_tracker_free include/linux/netdevice.h:4302 [inline] netdev_put include/linux/netdevice.h:4319 [inline] ax25_release+0x368/0x960 net/ax25/af_ax25.c:1080 __sock_release net/socket.c:647 [inline] sock_close+0xbc/0x240 net/socket.c:1398 __fput+0x3e9/0x9f0 fs/file_table.c:464 __do_sys_close fs/open.c:1580 [inline] __se_sys_close fs/open.c:1565 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1565 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... ================================================================Considering the issues above and the comments left in the code that say:"check if we can remove this feature. It is broken."; "autobinding in thismay or may not work"; - it is better to completely remove this feature thanto fix it because it is broken and leads to various kinds of memory bugs.Now calling connect() without first binding socket will result in anerror (-EINVAL). Userspace software that relies on the autobind featuremight get broken. However, this feature does not seem widely used withthis specific driver as it was not reliable at any point of time, and itis already broken anyway. E.g. ax25-tools and ax25-apps packages forpopular distributions do not use the autobind feature for AF_AX25.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22121 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix out-of-bound read in ext4_xattr_inode_dec_ref_all()There's issue as follows:BUG: KASAN: use-after-free in ext4_xattr_inode_dec_ref_all+0x6ff/0x790Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172CPU: 3 PID: 15172 Comm: syz-executor.0Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0xbe/0xfd lib/dump_stack.c:123 print_address_description.constprop.0+0x1e/0x280 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 ext4_xattr_inode_dec_ref_all+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4_xattr_delete_inode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4_evict_inode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iput_final fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4_orphan_cleanup fs/ext4/super.c:3298 [inline] ext4_fill_super+0x8c57/0xba40 fs/ext4/super.c:5300 mount_bdev+0x355/0x410 fs/super.c:1446 legacy_get_tree+0xfe/0x220 fs/fs_context.c:611 vfs_get_tree+0x8d/0x2f0 fs/super.c:1576 do_new_mount fs/namespace.c:2983 [inline] path_mount+0x119a/0x1ad0 fs/namespace.c:3316 do_mount+0xfc/0x110 fs/namespace.c:3329 __do_sys_mount fs/namespace.c:3540 [inline] __se_sys_mount+0x219/0x2e0 fs/namespace.c:3514 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00>ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffAbove issue happens as ext4_xattr_delete_inode() isn't check xattris valid if xattr is in inode.To solve above issue call xattr_check_inode() check if xattr if validin inode. In fact, we can directly verify in ext4_iget_extra_inode(),so that there is no divergent verification.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1,raid10: don't ignore IO flagsIf blk-wbt is enabled by default, it's found that raid write performanceis quite bad because all IO are throttled by wbt of underlying disks,due to flag REQ_IDLE is ignored. And turns out this behaviour exist sinceblk-wbt is introduced.Other than REQ_IDLE, other flags should not be ignored as well, forexample REQ_META can be set for filesystems, clearing it can cause priorityreverse problems; And REQ_NOWAIT should not be cleared as well, becauseio will wait instead of failing directly in underlying disks.Fix those problems by keep IO flags from master bio.Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dlm: prevent NPD when writing a positive value to event_donedo_uevent returns the value written to event_done. In case it is apositive value, new_lockspace would undo all the work, and lockspacewould not be set. __dlm_new_lockspace, however, would treat thatpositive value as a success due to commit 8511a2728ab8 ("dlm: fix usecount with multiple joins").Down the line, device_create_lockspace would pass that NULL lockspace todlm_find_lockspace_local, leading to a NULL pointer dereference.Treating such positive values as successes prevents the problem. Giventhis has been broken for so long, this is unlikely to break userspaceexpectations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23136 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: int340x: Add NULL check for adevNot all devices have an ACPI companion fwnode, so adev might be NULL.This is similar to the commit cd2fd6eab480("platform/x86: int3472: Check for adev == NULL").Add a check for adev not being set and return -ENODEV in that case toavoid a possible NULL pointer deref in int3402_thermal_probe().Note, under the same directory, int3400_thermal_probe() has such acheck.[ rjw: Subject edit, added Fixes: ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23140 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Avoid issue of interrupts remaining after request_irq errorAfter devm_request_irq() fails with error in pci_endpoint_test_request_irq(),the pci_endpoint_test_free_irq_vectors() is called assuming that all IRQshave been released.However, some requested IRQs remain unreleased, so there are still/proc/irq/* entries remaining, and this results in WARN() with thefollowing message: remove_proc_entry: removing non-empty directory 'irq/30', leaking at least 'pci-endpoint-test.0' WARNING: CPU: 0 PID: 202 at fs/proc/generic.c:719 remove_proc_entry +0x190/0x19cTo solve this issue, set the number of remaining IRQs to test->num_irqs,and release IRQs in advance by calling pci_endpoint_test_release_irq().[kwilczynski: commit log]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23142 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: detect and prevent references to a freed transport in sendmsgsctp_sendmsg() re-uses associations and transports when possible bydoing a lookup based on the socket endpoint and the message destinationaddress, and then sctp_sendmsg_to_asoc() sets the selected transport inall the message chunks to be sent.There's a possible race condition if another thread triggers the removalof that selected transport, for instance, by explicitly unbinding anaddress with setsockopt(SCTP_SOCKOPT_BINDX_REM), after the chunks havebeen set up and before the message is sent. This can happen if the sendbuffer is full, during the period when the sender thread temporarilyreleases the socket lock in sctp_wait_for_sndbuf().This causes the access to the transport data insctp_outq_select_transport(), when the association outqueue is flushed,to result in a use-after-free read.This change avoids this scenario by having sctp_transport_free() signalthe freeing of the transport, tagging it as "dead". In order to do this,the patch restores the "dead" bit in struct sctp_transport, which wasremoved incommit 47faa1e4c50e ("sctp: remove the dead field of sctp_transport").Then, in the scenario where the sender thread has released the socketlock in sctp_wait_for_sndbuf(), the bit is checked again afterre-acquiring the socket lock to detect the deletion. This is done whileholding a reference to the transport to prevent it from being freed inthe process.If the transport was deleted while the socket lock was relinquished,sctp_sendmsg_to_asoc() will return -EAGAIN to let userspace retry thesend.The bug was found by a private syzbot instance (see the error report [1]and the C reproducer that triggers it [2]).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23143 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix null-ptr-deref by sock_lock_init_class_and_name() and rmmod.When I ran the repro [0] and waited a few seconds, I observed twoLOCKDEP splats: a warning immediately followed by a null-ptr-deref. [1]Reproduction Steps: 1) Mount CIFS 2) Add an iptables rule to drop incoming FIN packets for CIFS 3) Unmount CIFS 4) Unload the CIFS module 5) Remove the iptables ruleAt step 3), the CIFS module calls sock_release() for the underlyingTCP socket, and it returns quickly. However, the socket remains inFIN_WAIT_1 because incoming FIN packets are dropped.At this point, the module's refcnt is 0 while the socket is stillalive, so the following rmmod command succeeds. # ss -tan State Recv-Q Send-Q Local Address:Port Peer Address:Port FIN-WAIT-1 0 477 10.0.2.15:51062 10.0.0.137:445 # lsmod | grep cifs cifs 1159168 0This highlights a discrepancy between the lifetime of the CIFS moduleand the underlying TCP socket. Even after CIFS calls sock_release()and it returns, the TCP socket does not die immediately in order toclose the connection gracefully.While this is generally fine, it causes an issue with LOCKDEP becauseCIFS assigns a different lock class to the TCP socket's sk->sk_lockusing sock_lock_init_class_and_name().Once an incoming packet is processed for the socket or a timer fires,sk->sk_lock is acquired.Then, LOCKDEP checks the lock context in check_wait_context(), wherehlock_class() is called to retrieve the lock class. However, sincethe module has already been unloaded, hlock_class() logs a warningand returns NULL, triggering the null-ptr-deref.If LOCKDEP is enabled, we must ensure that a module callingsock_lock_init_class_and_name() (CIFS, NFS, etc) cannot be unloadedwhile such a socket is still alive to prevent this issue.Let's hold the module reference in sock_lock_init_class_and_name()and release it when the socket is freed in sk_prot_free().Note that sock_lock_init() clears sk->sk_owner for svc_create_socket()that calls sock_lock_init_class_and_name() for a listening socket,which clones a socket by sk_clone_lock() without GFP_ZERO.[0]:CIFS_SERVER="10.0.0.137"CIFS_PATH="//${CIFS_SERVER}/Users/Administrator/Desktop/CIFS_TEST"DEV="enp0s3"CRED="/root/WindowsCredential.txt"MNT=$(mktemp -d /tmp/XXXXXX)mount -t cifs ${CIFS_PATH} ${MNT} -o vers=3.0,credentials=${CRED},cache=none,echo_interval=1iptables -A INPUT -s ${CIFS_SERVER} -j DROPfor i in $(seq 10);do umount ${MNT} rmmod cifs sleep 1donerm -r ${MNT}iptables -D INPUT -s ${CIFS_SERVER} -j DROP[1]:DEBUG_LOCKS_WARN_ON(1)WARNING: CPU: 10 PID: 0 at kernel/locking/lockdep.c:234 hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)Modules linked in: cifs_arc4 nls_ucs2_utils cifs_md4 [last unloaded: cifs]CPU: 10 UID: 0 PID: 0 Comm: swapper/10 Not tainted 6.14.0 #36Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:hlock_class (kernel/locking/lockdep.c:234 kernel/locking/lockdep.c:223)...Call Trace: __lock_acquire (kernel/locking/lockdep.c:4853 kernel/locking/lockdep.c:5178) lock_acquire (kernel/locking/lockdep.c:469 kernel/locking/lockdep.c:5853 kernel/locking/lockdep.c:5816) _raw_spin_lock_nested (kernel/locking/spinlock.c:379) tcp_v4_rcv (./include/linux/skbuff.h:1678 ./include/net/tcp.h:2547 net/ipv4/tcp_ipv4.c:2350)...BUG: kernel NULL pointer dereference, address: 00000000000000c4 PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present pagePGD 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 UID: 0 PID: 0 Comm: swapper/10 Tainted: G W 6.14.0 #36Tainted: [W]=WARNHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:__lock_acquire (kernel/---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23144 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: led_bl: Hold led_access lock when calling led_sysfs_disable()Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ...Indeed, led_sysfs_enable() has to be called with the led_accesslock held.Hold the lock when calling led_sysfs_disable().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23146 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: ene-kb3930: Fix a potential NULL pointer dereferenceThe off_gpios could be NULL. Add missing check in the kb3930_probe().This is similar to the issue fixed in commit b1ba8bcb2d1f("backlight: hx8357: Fix potential NULL pointer dereference").This was detected by our static analysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23147 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: Add NULL pointer check in i3c_master_queue_ibi()The I3C master driver may receive an IBI from a target device that has notbeen probed yet. In such cases, the master calls `i3c_master_queue_ibi()`to queue an IBI work task, leading to "Unable to handle kernel read fromunreadable memory" and resulting in a kernel panic.Typical IBI handling flow:1. The I3C master scans target devices and probes their respective drivers.2. The target device driver calls `i3c_device_request_ibi()` to enable IBI and assigns `dev->ibi = ibi`.3. The I3C master receives an IBI from the target device and calls `i3c_master_queue_ibi()` to queue the target device driver's IBI handler task.However, since target device events are asynchronous to the I3C probesequence, step 3 may occur before step 2, causing `dev->ibi` to be `NULL`,leading to a kernel panic.Add a NULL pointer check in `i3c_master_queue_ibi()` to prevent accessingan uninitialized `dev->ibi`, ensuring stability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23148 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: samsung: exynos-chipid: Add NULL pointer check in exynos_chipid_probe()soc_dev_attr->revision could be NULL, thus,a pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23150 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix off-by-one error in do_splitSyzkaller detected a use-after-free issue in ext4_insert_dentry that wascaused by out-of-bounds access due to incorrect splitting in do_split.BUG: KASAN: use-after-free in ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109Write of size 251 at addr ffff888074572f14 by task syz-executor335/5847CPU: 0 UID: 0 PID: 5847 Comm: syz-executor335 Not tainted 6.12.0-rc6-syzkaller-00318-ga9cda7c0ffed #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0x169/0x550 mm/kasan/report.c:488 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106 ext4_insert_dentry+0x36a/0x6d0 fs/ext4/namei.c:2109 add_dirent_to_buf+0x3d9/0x750 fs/ext4/namei.c:2154 make_indexed_dir+0xf98/0x1600 fs/ext4/namei.c:2351 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2455 ext4_add_nondir+0x8d/0x290 fs/ext4/namei.c:2796 ext4_symlink+0x920/0xb50 fs/ext4/namei.c:3431 vfs_symlink+0x137/0x2e0 fs/namei.c:4615 do_symlinkat+0x222/0x3a0 fs/namei.c:4641 __do_sys_symlink fs/namei.c:4662 [inline] __se_sys_symlink fs/namei.c:4660 [inline] __x64_sys_symlink+0x7a/0x90 fs/namei.c:4660 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The following loop is located right above 'if' statement.for (i = count-1; i >= 0; i--) { /* is more than half of this entry in 2nd half of the block? */ if (size + map[i].size/2 > blocksize/2) break; size += map[i].size; move++;}'i' in this case could go down to -1, in which case sum of active entrieswouldn't exceed half the block size, but previous behaviour would also dosplit in half if sum would exceed at the very last block, which in case ofhaving too many long name files in a single block could lead toout-of-bounds access and following use-after-free.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: refactor hfi packet parsing logicwords_count denotes the number of words in total payload, while datapoints to payload of various property within it. When words_countreaches last word, data can access memory beyond the total payload. Thiscan lead to OOB access. With this patch, the utility api for handlingindividual properties now returns the size of data consumed. Accordinglyremaining bytes are calculated before parsing the payload, therebyeliminates the OOB access possibilities.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23157 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi_parser: add check to avoid out of bound accessThere is a possibility that init_codecs is invoked multiple times duringmanipulated payload from video firmware. In such case, if codecs_countcan get incremented to value more than MAX_CODEC_NUM, there can be OOBaccess. Reset the count so that it always starts from beginning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23158 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add check to handle incorrect queue sizeqsize represents size of shared queued between driver and videofirmware. Firmware can modify this value to an invalid large value. Insuch situation, empty_space will be bigger than the space actuallyavailable. Since new_wr_idx is not checked, so the following code willresult in an OOB write....qsize = qhdr->q_sizeif (wr_idx >= rd_idx) empty_space = qsize - (wr_idx - rd_idx)....if (new_wr_idx < qsize) { memcpy(wr_ptr, packet, dwords << 2) --> OOB writeAdd check to ensure qsize is within the allocated size whilereading and writing packets into the queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23159 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: hfi: add a check to handle OOB in sfr regionsfr->buf_size is in shared memory and can be modified by malicious user.OOB write is possible when the size is made higher than actual sfr databuffer. Cap the size to allocated size for such cases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23161 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: vmd: Make vmd_dev::cfg_lock a raw_spinlock_t typeThe access to the PCI config space via pci_ops::read and pci_ops::write isa low-level hardware access. The functions can be accessed with disabledinterrupts even on PREEMPT_RT. The pci_lock is a raw_spinlock_t for thispurpose.A spinlock_t becomes a sleeping lock on PREEMPT_RT, so it cannot beacquired with disabled interrupts. The vmd_dev::cfg_lock is accessed inthe same context as the pci_lock.Make vmd_dev::cfg_lock a raw_spinlock_t type so it can be used withinterrupts disabled.This was reported as: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 Call Trace: rt_spin_lock+0x4e/0x130 vmd_pci_read+0x8d/0x100 [vmd] pci_user_read_config_byte+0x6f/0xe0 pci_read_config+0xfe/0x290 sysfs_kf_bin_read+0x68/0x90[bigeasy: reword commit message]Tested-off-by: Luis Claudio R. Goncalves [kwilczynski: commit log][bhelgaas: add back report info fromhttps://lore.kernel.org/lkml/20241218115951.83062-1-ryotkkr98@gmail.com/]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-23163 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: vlan: don't propagate flags on openWith the device instance lock, there is now a possibility of a deadlock:[ 1.211455] ============================================[ 1.211571] WARNING: possible recursive locking detected[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted[ 1.211823] --------------------------------------------[ 1.211936] ip/184 is trying to acquire lock:[ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0[ 1.212207][ 1.212207] but task is already holding lock:[ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.212487][ 1.212487] other info that might help us debug this:[ 1.212626] Possible unsafe locking scenario:[ 1.212626][ 1.212751] CPU0[ 1.212815] ----[ 1.212871] lock(&dev->lock);[ 1.212944] lock(&dev->lock);[ 1.213016][ 1.213016] *** DEADLOCK ***[ 1.213016][ 1.213143] May be due to missing lock nesting notation[ 1.213143][ 1.213294] 3 locks held by ip/184:[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0[ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0[ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0[ 1.213895][ 1.213895] stack backtrace:[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014[ 1.213994] Call Trace:[ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0[ 1.214000] print_deadlock_bug+0x28b/0x2a0[ 1.214020] lock_acquire+0xea/0x2a0[ 1.214027] __mutex_lock+0xbf/0xd40[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev[ 1.214042] __dev_open+0x145/0x270[ 1.214046] __dev_change_flags+0xb0/0x1e0[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0[ 1.214058] notifier_call_chain+0x78/0x120[ 1.214062] netif_open+0x6d/0x90[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0[ 1.214066] bond_enslave+0x64c/0x1230[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0[ 1.214077] do_setlink+0x516/0x13b0[ 1.214094] rtnl_newlink+0xaba/0xb80[ 1.214132] rtnetlink_rcv_msg+0x440/0x490[ 1.214144] netlink_rcv_skb+0xeb/0x120[ 1.214150] netlink_unicast+0x1f9/0x320[ 1.214153] netlink_sendmsg+0x346/0x3f0[ 1.214157] __sock_sendmsg+0x86/0xb0[ 1.214160] ____sys_sendmsg+0x1c8/0x220[ 1.214164] ___sys_sendmsg+0x28f/0x2d0[ 1.214179] __x64_sys_sendmsg+0xef/0x140[ 1.214184] do_syscall_64+0xec/0x1d0[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 1.214191] RIP: 0033:0x7f2d1b4a7e56Device setup: netdevsim0 (down) ^ ^ bond netdevsim1.100@netdevsim1 allmulticast=on (down)When we enslave the lower device (netdevsim0) which has a vlan, wepropagate vlan's allmuti/promisc flags during ndo_open. This causes(re)locking on of the real_dev.Propagate allmulti/promisc on flags change, not on the open. Thereis a slight semantics change that vlans that are down now propagatethe flags, but this seems unlikely to result in the real issues.Reproducer: echo 0 1 > /sys/bus/netdevsim/new_device dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev) ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix UAF in decryption with multichannelAfter commit f7025d861694 ("smb: client: allocate crypto only forprimary server") and commit b0abcd65ec54 ("smb: client: fix UAF inasync decryption"), the channels started reusing AEAD TFM from primarychannel to perform synchronous decryption, but that can't done asthere could be multiple cifsd threads (one per channel) simultaneouslyaccessing it to perform decryption.This fixes the following KASAN splat when running fstest generic/249with 'vers=3.1.1,multichannel,max_channels=4,seal' against WindowsServer 2022:BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110Read of size 8 at addr ffff8881046c18a0 by task cifsd/986CPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1PREEMPT(voluntary)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc4104/01/2014Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x156/0x528 ? gf128mul_4k_lle+0xba/0x110 ? __virt_addr_valid+0x145/0x300 ? __phys_addr+0x46/0x90 ? gf128mul_4k_lle+0xba/0x110 kasan_report+0xdf/0x1a0 ? gf128mul_4k_lle+0xba/0x110 gf128mul_4k_lle+0xba/0x110 ghash_update+0x189/0x210 shash_ahash_update+0x295/0x370 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_shash_ahash_update+0x10/0x10 ? __pfx_extract_iter_to_sg+0x10/0x10 ? ___kmalloc_large_node+0x10e/0x180 ? __asan_memset+0x23/0x50 crypto_ahash_update+0x3c/0xc0 gcm_hash_assoc_remain_continue+0x93/0xc0 crypt_message+0xe09/0xec0 [cifs] ? __pfx_crypt_message+0x10/0x10 [cifs] ? _raw_spin_unlock+0x23/0x40 ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs] decrypt_raw_data+0x229/0x380 [cifs] ? __pfx_decrypt_raw_data+0x10/0x10 [cifs] ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs] smb3_receive_transform+0x837/0xc80 [cifs] ? __pfx_smb3_receive_transform+0x10/0x10 [cifs] ? __pfx___might_resched+0x10/0x10 ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs] cifs_demultiplex_thread+0x692/0x1570 [cifs] ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] ? rcu_is_watching+0x20/0x50 ? rcu_lockdep_current_cpu_online+0x62/0xb0 ? find_held_lock+0x32/0x90 ? kvm_sched_clock_read+0x11/0x20 ? local_clock_noinstr+0xd/0xd0 ? trace_irq_enable.constprop.0+0xa8/0xe0 ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs] kthread+0x1fe/0x380 ? kthread+0x10f/0x380 ? __pfx_kthread+0x10/0x10 ? local_clock_noinstr+0xd/0xd0 ? ret_from_fork+0x1b/0x60 ? local_clock+0x15/0x30 ? lock_release+0x29b/0x390 ? rcu_is_watching+0x20/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x60 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37756 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: tls: explicitly disallow disconnectsyzbot discovered that it can disconnect a TLS socket and thenrun into all sort of unexpected corner cases. I have a vaguerecollection of Eric pointing this out to us a long time ago.Supporting disconnect is really hard, for one thing if offloadis enabled we'd need to wait for all packets to be _acked_.Disconnect is not commonly used, disallow it.The immediate problem syzbot run into is the warning in the strp,but that's just the easiest bug to trigger: WARNING: CPU: 0 PID: 5834 at net/tls/tls_strp.c:486 tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 RIP: 0010:tls_strp_msg_load+0x72e/0xa80 net/tls/tls_strp.c:486 Call Trace: tls_rx_rec_wait+0x280/0xa60 net/tls/tls_sw.c:1363 tls_sw_recvmsg+0x85c/0x1c30 net/tls/tls_sw.c:2043 inet6_recvmsg+0x2c9/0x730 net/ipv6/af_inet6.c:678 sock_recvmsg_nosec net/socket.c:1023 [inline] sock_recvmsg+0x109/0x280 net/socket.c:1045 __sys_recvfrom+0x202/0x380 net/socket.c:2237

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix memory leak in tipc_link_xmitIn case the backlog transmit queue for system-importance messages is overloaded,tipc_link_xmit() returns -ENOBUFS but the skb list is not purged. This leads tomemory leak and failure when a skb is allocated.This commit fixes this issue by purging the skb list before tipc_link_xmit()returns.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: prime: fix ttm_bo_delayed_delete oopsFix an oops in ttm_bo_delayed_delete which results from dererencing adangling pointer:Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMPCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216Hardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024Workqueue: ttm ttm_bo_delayed_delete [ttm]RIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290Code: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8bRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202RAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6bR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383ccFS: 0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0PKRU: 55555554Call Trace: ? __die_body.cold+0x19/0x26 ? die_addr+0x3d/0x70 ? exc_general_protection+0x159/0x460 ? asm_exc_general_protection+0x27/0x30 ? dma_resv_iter_first_unlocked+0x55/0x290 dma_resv_wait_timeout+0x56/0x100 ttm_bo_delayed_delete+0x69/0xb0 [ttm] process_one_work+0x217/0x5c0 worker_thread+0x1c8/0x3d0 ? apply_wqattrs_cleanup.part.0+0xc0/0xc0 kthread+0x10b/0x240 ? kthreads_online_cpu+0x140/0x140 ret_from_fork+0x40/0x70 ? kthreads_online_cpu+0x140/0x140 ret_from_fork_asm+0x11/0x20 The cause of this is:- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the reference to the shared dma_buf. The reference count is 0, so the dma_buf is destroyed, which in turn decrements the corresponding amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed - calling drm_gem_object_release then dma_resv_fini (which destroys the reservation object), then finally freeing the amdgpu_bo.- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory formerly allocated to the amdgpu_bo.- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls ttm_bo_release, which schedules ttm_bo_delayed_delete.- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer, resulting in a general protection fault.Fix this by moving the drm_prime_gem_destroy call fromnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it willbe run after ttm_bo_delayed_delete.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37770 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Prevent division by zeroThe user can set any speed value.If speed is greater than UINT_MAX/8, division by zero is possible.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37773 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtiofs: add filesystem context source name checkIn certain scenarios, for example, during fuzz testing, the sourcename may be NULL, which could lead to a kernel panic. Therefore, anextra check for the source name should be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:isofs: Prevent the use of too small fidsyzbot reported a slab-out-of-bounds Read in isofs_fh_to_parent. [1]The handle_bytes value passed in by the reproducing program is equal to 12.In handle_to_path(), only 12 bytes of memory are allocated for the structurefile_handle->f_handle member, which causes an out-of-bounds access whenaccessing the member parent_block of the structure isofs_fid in isofs,because accessing parent_block requires at least 16 bytes of f_handle.Here, fh_len is used to indirectly confirm that the value of handle_bytesis greater than 3 before accessing parent_block.[1]BUG: KASAN: slab-out-of-bounds in isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183Read of size 4 at addr ffff0000cc030d94 by task syz-executor215/6466CPU: 1 UID: 0 PID: 6466 Comm: syz-executor215 Not tainted 6.14.0-rc7-syzkaller-ga2392f333575 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:466 (C) __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0xe4/0x150 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0x198/0x550 mm/kasan/report.c:521 kasan_report+0xd8/0x138 mm/kasan/report.c:634 __asan_report_load4_noabort+0x20/0x2c mm/kasan/report_generic.c:380 isofs_fh_to_parent+0x1b8/0x210 fs/isofs/export.c:183 exportfs_decode_fh_raw+0x2dc/0x608 fs/exportfs/expfs.c:523 do_handle_to_path+0xa0/0x198 fs/fhandle.c:257 handle_to_path fs/fhandle.c:385 [inline] do_handle_open+0x8cc/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600Allocated by task 6466: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x40/0x78 mm/kasan/common.c:68 kasan_save_alloc_info+0x40/0x50 mm/kasan/generic.c:562 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0xac/0xc4 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __do_kmalloc_node mm/slub.c:4294 [inline] __kmalloc_noprof+0x32c/0x54c mm/slub.c:4306 kmalloc_noprof include/linux/slab.h:905 [inline] handle_to_path fs/fhandle.c:357 [inline] do_handle_open+0x5a4/0xb8c fs/fhandle.c:403 __do_sys_open_by_handle_at fs/fhandle.c:443 [inline] __se_sys_open_by_handle_at fs/fhandle.c:434 [inline] __arm64_sys_open_by_handle_at+0x80/0x94 fs/fhandle.c:434 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:744 el0t_64_sync_handler+0x84/0x108 arch/arm64/kernel/entry-common.c:762 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37781 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: cros-ec-tunnel: defer probe if parent EC is not presentWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parentdevice will not be found, leading to NULL pointer dereference.That can also be reproduced by unbinding the controller driver and thenloading i2c-cros-ec-tunnel module (or binding the device).[ 271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058[ 271.998215] #PF: supervisor read access in kernel mode[ 272.003351] #PF: error_code(0x0000) - not-present page[ 272.008485] PGD 0 P4D 0[ 272.011022] Oops: Oops: 0000 [#1] SMP NOPTI[ 272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S 6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full) 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5[ 272.030312] Tainted: [S]=CPU_OUT_OF_SPEC[ 272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021[ 272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel][ 272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9[ 272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282[ 272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000[ 272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00[ 272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000[ 272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000[ 272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10[ 272.108198] FS: 00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000[ 272.116282] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0[ 272.129155] Call Trace:[ 272.131606] [ 272.133709] ? acpi_dev_pm_attach+0xdd/0x110[ 272.137985] platform_probe+0x69/0xa0[ 272.141652] really_probe+0x152/0x310[ 272.145318] __driver_probe_device+0x77/0x110[ 272.149678] driver_probe_device+0x1e/0x190[ 272.153864] __driver_attach+0x10b/0x1e0[ 272.157790] ? driver_attach+0x20/0x20[ 272.161542] bus_for_each_dev+0x107/0x150[ 272.165553] bus_add_driver+0x15d/0x270[ 272.169392] driver_register+0x65/0x110[ 272.173232] ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698][ 272.182617] do_one_initcall+0x110/0x350[ 272.186543] ? security_kernfs_init_security+0x49/0xd0[ 272.191682] ? __kernfs_new_node+0x1b9/0x240[ 272.195954] ? security_kernfs_init_security+0x49/0xd0[ 272.201093] ? __kernfs_new_node+0x1b9/0x240[ 272.205365] ? kernfs_link_sibling+0x105/0x130[ 272.209810] ? kernfs_next_descendant_post+0x1c/0xa0[ 272.214773] ? kernfs_activate+0x57/0x70[ 272.218699] ? kernfs_add_one+0x118/0x160[ 272.222710] ? __kernfs_create_file+0x71/0xa0[ 272.227069] ? sysfs_add_bin_file_mode_ns+0xd6/0x110[ 272.232033] ? internal_create_group+0x453/0x4a0[ 272.236651] ? __vunmap_range_noflush+0x214/0x2d0[ 272.241355] ? __free_frozen_pages+0x1dc/0x420[ 272.245799] ? free_vmap_area_noflush+0x10a/0x1c0[ 272.250505] ? load_module+0x1509/0x16f0[ 272.254431] do_init_module+0x60/0x230[ 272.258181] __se_sys_finit_module+0x27a/0x370[ 272.262627] do_syscall_64+0x6a/0xf0[ 272.266206] ? do_syscall_64+0x76/0xf0[ 272.269956] ? irqentry_exit_to_user_mode+0x79/0x90[ 272.274836] entry_SYSCALL_64_after_hwframe+0x55/0x5d[ 272.279887] RIP: 0033:0x7b9309168d39[ 272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8[ 272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37786 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: free routing table on probe failureIf complete = true in dsa_tree_setup(), it means that we are the lastswitch of the tree which is successfully probing, and we should besetting up all switches from our probe path.After "complete" becomes true, dsa_tree_setup_cpu_ports() or anysubsequent function may fail. If that happens, the entire tree setup isin limbo: the first N-1 switches have successfully finished probing(doing nothing but having allocated persistent memory in the tree'sdst->ports, and maybe dst->rtable), and switch N failed to probe, endingthe tree setup process before anything is tangible from the user's PoV.If switch N fails to probe, its memory (ports) will be freed and removedfrom dst->ports. However, the dst->rtable elements pointing to its ports,as created by dsa_link_touch(), will remain there, and will lead touse-after-free if dereferenced.If dsa_tree_setup_switches() returns -EPROBE_DEFER, which is entirelypossible because that is where ds->ops->setup() is, we get a kasanreport like this:==================================================================BUG: KASAN: slab-use-after-free in mv88e6xxx_setup_upstream_port+0x240/0x568Read of size 8 at addr ffff000004f56020 by task kworker/u8:3/42Call trace: __asan_report_load8_noabort+0x20/0x30 mv88e6xxx_setup_upstream_port+0x240/0x568 mv88e6xxx_setup+0xebc/0x1eb0 dsa_register_switch+0x1af4/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Allocated by task 42: __kasan_kmalloc+0x84/0xa0 __kmalloc_cache_noprof+0x298/0x490 dsa_switch_touch_ports+0x174/0x3d8 dsa_register_switch+0x800/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350Freed by task 42: __kasan_slab_free+0x48/0x68 kfree+0x138/0x418 dsa_register_switch+0x2694/0x2ae0 mv88e6xxx_register_switch+0x1b8/0x2a8 mv88e6xxx_probe+0xc4c/0xf60 mdio_probe+0x78/0xb8 really_probe+0x2b8/0x5a8 __driver_probe_device+0x164/0x298 driver_probe_device+0x78/0x258 __device_attach_driver+0x274/0x350The simplest way to fix the bug is to delete the routing table in itsentirety. dsa_tree_setup_routing_table() has no problem in regeneratingit even if we deleted links between ports other than those of switch N,because dsa_link_touch() first checks whether the port pair alreadyexists in dst->rtable, allocating if not.The deletion of the routing table in its entirety already exists indsa_tree_teardown(), so refactor that into a function that can also becalled from the tree setup error path.In my analysis of the commit to blame, it is the one which addeddsa_link elements to dst->rtable. Prior to that, each switch had its ownds->rtable which is freed when the switch fails to probe. But the treeis potentially persistent memory.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: avoid unregistering devlink regions which were never registeredRussell King reports that a system with mv88e6xxx dereferences a NULLpointer when unbinding this driver:https://lore.kernel.org/netdev/Z_lRkMlTJ1KQ0kVX@shell.armlinux.org.uk/The crash seems to be in devlink_region_destroy(), which is not NULLtolerant but is given a NULL devlink global region pointer.At least on some chips, some devlink regions are conditionally registeredsince the blamed commit, see mv88e6xxx_setup_devlink_regions_global(): if (cond && !cond(chip)) continue;These are MV88E6XXX_REGION_STU and MV88E6XXX_REGION_PVT. If the chipdoes not have an STU or PVT, it should crash like this.To fix the issue, avoid unregistering those regions which are NULL, i.e.were skipped at mv88e6xxx_setup_devlink_regions_global() time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37788 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cxgb4: fix memory leak in cxgb4_init_ethtool_filters() error pathIn the for loop used to allocate the loc_array and bmap for each port, amemory leak is possible when the allocation for loc_array succeeds,but the allocation for bmap fails. This is because when the control flowgoes to the label free_eth_finfo, only the allocations starting from(i-1)th iteration are freed.Fix that by freeing the loc_array in the bmap allocation error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37792 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btrtl: Prevent potential NULL dereferenceThe btrtl_initialize() function checks that rtl_load_file() eitherhad an error or it loaded a zero length file. However, if it loadeda zero length file then the error code is not set correctly. Itresults in an error pointer vs NULL bug, followed by a NULL pointerdereference. This was detected by Smatch:drivers/bluetooth/btrtl.c:592 btrtl_initialize() warn: passing zero to 'ERR_PTR'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: Purge vif txq in ieee80211_do_stop()After ieee80211_do_stop() SKB from vif's txq could still be processed.Indeed another concurrent vif schedule_and_wake_txq call could causethose packets to be dequeued (see ieee80211_handle_wake_tx_queue())without checking the sdata current state.Because vif.drv_priv is now cleared in this function, this could lead todriver crash.For example in ath12k, ahvif is store in vif.drv_priv. Thus ifath12k_mac_op_tx() is called after ieee80211_do_stop(), ahvif->ah can beNULL, leading the ath12k_warn(ahvif->ah,...) call in this function totrigger the NULL deref below. Unable to handle kernel paging request at virtual address dfffffc000000001 KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] batman_adv: bat0: Interface deactivated: brbh1337 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [dfffffc000000001] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP CPU: 1 UID: 0 PID: 978 Comm: lbd Not tainted 6.13.0-g633f875b8f1e #114 Hardware name: HW (DT) pstate: 10000005 (nzcV daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] lr : ath12k_mac_op_tx+0x174/0x29b8 [ath12k] sp : ffffffc086ace450 x29: ffffffc086ace450 x28: 0000000000000000 x27: 1ffffff810d59ca4 x26: ffffff801d05f7c0 x25: 0000000000000000 x24: 000000004000001e x23: ffffff8009ce4926 x22: ffffff801f9c0800 x21: ffffff801d05f7f0 x20: ffffff8034a19f40 x19: 0000000000000000 x18: ffffff801f9c0958 x17: ffffff800bc0a504 x16: dfffffc000000000 x15: ffffffc086ace4f8 x14: ffffff801d05f83c x13: 0000000000000000 x12: ffffffb003a0bf03 x11: 0000000000000000 x10: ffffffb003a0bf02 x9 : ffffff8034a19f40 x8 : ffffff801d05f818 x7 : 1ffffff0069433dc x6 : ffffff8034a19ee0 x5 : ffffff801d05f7f0 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000008 Call trace: ath12k_mac_op_tx+0x6cc/0x29b8 [ath12k] (P) ieee80211_handle_wake_tx_queue+0x16c/0x260 ieee80211_queue_skb+0xeec/0x1d20 ieee80211_tx+0x200/0x2c8 ieee80211_xmit+0x22c/0x338 __ieee80211_subif_start_xmit+0x7e8/0xc60 ieee80211_subif_start_xmit+0xc4/0xee0 __ieee80211_subif_start_xmit_8023.isra.0+0x854/0x17a0 ieee80211_subif_start_xmit_8023+0x124/0x488 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 br_dev_queue_push_xmit+0x120/0x4a8 __br_forward+0xe4/0x2b0 deliver_clone+0x5c/0xd0 br_flood+0x398/0x580 br_dev_xmit+0x454/0x9f8 dev_hard_start_xmit+0x160/0x5a8 __dev_queue_xmit+0x6f8/0x3120 ip6_finish_output2+0xc28/0x1b60 __ip6_finish_output+0x38c/0x638 ip6_output+0x1b4/0x338 ip6_local_out+0x7c/0xa8 ip6_send_skb+0x7c/0x1b0 ip6_push_pending_frames+0x94/0xd0 rawv6_sendmsg+0x1a98/0x2898 inet_sendmsg+0x94/0xe0 __sys_sendto+0x1e4/0x308 __arm64_sys_sendto+0xc4/0x140 do_el0_svc+0x110/0x280 el0_svc+0x20/0x60 el0t_64_sync_handler+0x104/0x138 el0t_64_sync+0x154/0x158To avoid that, empty vif's txq at ieee80211_do_stop() so no packet couldbe dequeued after ieee80211_do_stop() (new packets cannot be queuedbecause SDATA_STATE_RUNNING is cleared at this point).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: at76c50x: fix use after free access in at76_disconnectThe memory pointed to by priv is freed at the end of at76_delete_devicefunction (using ieee80211_free_hw). But the code then accesses the udevfield of the freed object to put the USB device. This may also lead to amemory leak of the usb device. Fix this by using udev from interface.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37803 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udmabuf: fix a buf size overflow issue during udmabuf creationby casting size_limit_mb to u64 when calculate pglimit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37804 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mcb: fix a double free bug in chameleon_parse_gdd()In chameleon_parse_gdd(), if mcb_device_register() fails, 'mdev'would be released in mcb_device_register() via put_device().Thus, goto 'err' label and free 'mdev' again causes a double free.Just return if mcb_device_register() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/gic-v2m: Prevent use after free of gicv2m_get_fwnode()With ACPI in place, gicv2m_get_fwnode() is registered with the pcisubsystem as pci_msi_get_fwnode_cb(), which may get invoked at runtimeduring a PCI host bridge probe. But, the call back is wrongly marked as__init, causing it to be freed, while being registered with the PCIsubsystem and could trigger: Unable to handle kernel paging request at virtual address ffff8000816c0400 gicv2m_get_fwnode+0x0/0x58 (P) pci_set_bus_msi_domain+0x74/0x88 pci_register_host_bridge+0x194/0x548This is easily reproducible on a Juno board with ACPI boot.Retain the function for later use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37820 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xen-netfront: handle NULL returned by xdp_convert_buff_to_frame()The function xdp_convert_buff_to_frame() may return NULL if it failsto correctly convert the XDP buffer into an XDP frame due to memoryconstraints, internal errors, or invalid data. Failing to check for NULLmay lead to a NULL pointer dereference if the result is used later inprocessing, potentially causing crashes, data corruption, or undefinedbehavior.On XDP redirect failure, the associated page must be released explicitlyif it was previously retained via get_page(). Failing to do so may resultin a memory leak, as the pages reference count is not decremented.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37824 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix NULL pointer dereference in tipc_mon_reinit_self()syzbot reported:tipc: Node number set to 1055423674Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014Workqueue: events tipc_net_finalize_workRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140 process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3319 [inline] worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400 kthread+0x3c2/0x780 kernel/kthread.c:464 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 ...RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719...RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cbaRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400There is a racing condition between workqueue created when enablingbearer and another thread created when disabling bearer right afterthat as follow:enabling_bearer | disabling_bearer--------------- | ----------------tipc_disc_timeout() |{ | bearer_disable() ... | { schedule_work(&tn->work); | tipc_mon_delete() ... | {} | ... | write_lock_bh(&mon->lock); | mon->self = NULL; | write_unlock_bh(&mon->lock); | ... | }tipc_net_finalize_work() | }{ | ... | tipc_net_finalize() | { | ... | tipc_mon_reinit_self() | { | ... | write_lock_bh(&mon->lock); | mon->self->addr = tipc_own_addr(net); | write_unlock_bh(&mon->lock); | ... ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scpi: Fix null-ptr-deref in scpi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scpi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37830 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: scmi: Fix null-ptr-deref in scmi_cpufreq_get_rate()cpufreq_cpu_get_raw() can return NULL when the target CPU is not presentin the policy->cpus mask. scmi_cpufreq_get_rate() does not check forthis case, which results in a NULL pointer dereference.Add NULL check after cpufreq_cpu_get_raw() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/niu: Niu requires MSIX ENTRY_DATA fields touch before entry readsFix niu_try_msix() to not cause a fatal trap on sparc systems.Set PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev towork around a bug in the hardware or firmware.For each vector entry in the msix table, niu chips will cause a fataltrap if any registers in that entry are read before that entries'ENTRY_DATA register is written to. Testing indicates writes to otherregisters are not sufficient to prevent the fatal trap, however the valuedoes not appear to matter. This only needs to happen once after power up,so simply rebooting into a kernel lacking this fix will NOT cause thetrap.NON-RESUMABLE ERROR: Reporting on cpu 64NON-RESUMABLE ERROR: TPC [0x00000000005f6900] NON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffffNON-RESUMABLE ERROR: 0000000800000000:0000000000000000:0000000000000000:0000000000000000]NON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]NON-RESUMABLE ERROR: type [precise nonresumable]NON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >NON-RESUMABLE ERROR: raddr [0xffffffffffffffff]NON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]NON-RESUMABLE ERROR: size [0x8]NON-RESUMABLE ERROR: asi [0x00]CPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63Workqueue: events work_for_cpu_fnTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000 Not taintedTPC: g0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100g4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000o0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620o4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128RPC: <__pci_enable_msix_range+0x3cc/0x460>l0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020l4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734i0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000di4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0I7: Call Trace:[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu][<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu][<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu][<00000000005ef3e4>] local_pci_probe+0x28/0x74[<0000000000469240>] work_for_cpu_fn+0x8/0x1c[<000000000046b008>] process_scheduled_works+0x144/0x210[<000000000046b518>] worker_thread+0x13c/0x1c0[<00000000004710e0>] kthread+0xb8/0xc8[<00000000004060c8>] ret_from_fork+0x1c/0x2c[<0000000000000000>] 0x0Kernel panic - not syncing: Non-resumable error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37836 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Fix reference leak in pci_register_host_bridge()If device_register() fails, call put_device() to give up the reference toavoid a memory leak, per the comment at device_register().Found by code review.[bhelgaas: squash Dan Carpenter's double free fix fromhttps://lore.kernel.org/r/db806a6c-a91b-4e5a-a84b-6b7e01bdac85@stanley.mountain]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37840 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: brcmnand: fix PM resume warningFixed warning on PM resume as shown below caused due to uninitializedstruct nand_operation that checks chip select field :WARN_ON(op->cs >= nanddev_ntargets(&chip->base)[ 14.588522] ------------[ cut here ]------------[ 14.588529] WARNING: CPU: 0 PID: 1392 at drivers/mtd/nand/raw/internals.h:139 nand_reset_op+0x1e0/0x1f8[ 14.588553] Modules linked in: bdc udc_core[ 14.588579] CPU: 0 UID: 0 PID: 1392 Comm: rtcwake Tainted: G W 6.14.0-rc4-g5394eea10651 #16[ 14.588590] Tainted: [W]=WARN[ 14.588593] Hardware name: Broadcom STB (Flattened Device Tree)[ 14.588598] Call trace:[ 14.588604] dump_backtrace from show_stack+0x18/0x1c[ 14.588622] r7:00000009 r6:0000008b r5:60000153 r4:c0fa558c[ 14.588625] show_stack from dump_stack_lvl+0x70/0x7c[ 14.588639] dump_stack_lvl from dump_stack+0x18/0x1c[ 14.588653] r5:c08d40b0 r4:c1003cb0[ 14.588656] dump_stack from __warn+0x84/0xe4[ 14.588668] __warn from warn_slowpath_fmt+0x18c/0x194[ 14.588678] r7:c08d40b0 r6:c1003cb0 r5:00000000 r4:00000000[ 14.588681] warn_slowpath_fmt from nand_reset_op+0x1e0/0x1f8[ 14.588695] r8:70c40dff r7:89705f41 r6:36b4a597 r5:c26c9444 r4:c26b0048[ 14.588697] nand_reset_op from brcmnand_resume+0x13c/0x150[ 14.588714] r9:00000000 r8:00000000 r7:c24f8010 r6:c228a3f8 r5:c26c94bc r4:c26b0040[ 14.588717] brcmnand_resume from platform_pm_resume+0x34/0x54[ 14.588735] r5:00000010 r4:c0840a50[ 14.588738] platform_pm_resume from dpm_run_callback+0x5c/0x14c[ 14.588757] dpm_run_callback from device_resume+0xc0/0x324[ 14.588776] r9:c24f8054 r8:c24f80a0 r7:00000000 r6:00000000 r5:00000010 r4:c24f8010[ 14.588779] device_resume from dpm_resume+0x130/0x160[ 14.588799] r9:c22539e4 r8:00000010 r7:c22bebb0 r6:c24f8010 r5:c22539dc r4:c22539b0[ 14.588802] dpm_resume from dpm_resume_end+0x14/0x20[ 14.588822] r10:c2204e40 r9:00000000 r8:c228a3fc r7:00000000 r6:00000003 r5:c228a414[ 14.588826] r4:00000010[ 14.588828] dpm_resume_end from suspend_devices_and_enter+0x274/0x6f8[ 14.588848] r5:c228a414 r4:00000000[ 14.588851] suspend_devices_and_enter from pm_suspend+0x228/0x2bc[ 14.588868] r10:c3502910 r9:c3501f40 r8:00000004 r7:c228a438 r6:c0f95e18 r5:00000000[ 14.588871] r4:00000003[ 14.588874] pm_suspend from state_store+0x74/0xd0[ 14.588889] r7:c228a438 r6:c0f934c8 r5:00000003 r4:00000003[ 14.588892] state_store from kobj_attr_store+0x1c/0x28[ 14.588913] r9:00000000 r8:00000000 r7:f09f9f08 r6:00000004 r5:c3502900 r4:c0283250[ 14.588916] kobj_attr_store from sysfs_kf_write+0x40/0x4c[ 14.588936] r5:c3502900 r4:c0d92a48[ 14.588939] sysfs_kf_write from kernfs_fop_write_iter+0x104/0x1f0[ 14.588956] r5:c3502900 r4:c3501f40[ 14.588960] kernfs_fop_write_iter from vfs_write+0x250/0x420[ 14.588980] r10:c0e14b48 r9:00000000 r8:c25f5780 r7:00443398 r6:f09f9f68 r5:c34f7f00[ 14.588983] r4:c042a88c[ 14.588987] vfs_write from ksys_write+0x74/0xe4[ 14.589005] r10:00000004 r9:c25f5780 r8:c02002fA0 r7:00000000 r6:00000000 r5:c34f7f00[ 14.589008] r4:c34f7f00[ 14.589011] ksys_write from sys_write+0x10/0x14[ 14.589029] r7:00000004 r6:004421c0 r5:00443398 r4:00000004[ 14.589032] sys_write from ret_fast_syscall+0x0/0x5c[ 14.589044] Exception stack(0xf09f9fa8 to 0xf09f9ff0)[ 14.589050] 9fa0: 00000004 00443398 00000004 00443398 00000004 00000001[ 14.589056] 9fc0: 00000004 00443398 004421c0 00000004 b6ecbd58 00000008 bebfbc38 0043eb78[ 14.589062] 9fe0: 00440eb0 bebfbaf8 b6de18a0 b6e579e8[ 14.589065] ---[ end trace 0000000000000000 ]---The fix uses the higher level nand_reset(chip, chipnr); where chipnr = 0, whendoing PM resume operation in compliance with the controller support for singledie nand chip. Switching from nand_reset_op() to nan---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:spi: fsl-qspi: use devm function instead of driver removeDriver use devm APIs to manage clk/irq/resources and register the spicontroller, but the legacy remove function will be called first duringdevice detach and trigger kernel panic. Drop the remove function and usedevm_add_action_or_reset() for driver cleanup to ensure the releasesequence.Trigger kernel panic on i.MX8MQ byecho 30bb0000.spi >/sys/bus/platform/drivers/fsl-quadspi/unbind

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: avoid NULL pointer dereference in dbg callcifs_server_dbg() implies server to be non-NULL somove call under condition to avoid NULL pointer dereference.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37850 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pwm: mediatek: Prevent divide-by-zero in pwm_mediatek_config()With CONFIG_COMPILE_TEST && !CONFIG_HAVE_CLK, pwm_mediatek_config() has adivide-by-zero in the following line: do_div(resolution, clk_get_rate(pc->clk_pwms[pwm->hwpwm]));due to the fact that the !CONFIG_HAVE_CLK version of clk_get_rate()returns zero.This is presumably just a theoretical problem: COMPILE_TEST overridesthe dependency on RALINK which would select COMMON_CLK. Regardless it'sa good idea to check for the error explicitly to avoid divide-by-zero.Fixes the following warning: drivers/pwm/pwm-mediatek.o: warning: objtool: .text: unexpected end of section[ukleinek: s/CONFIG_CLK/CONFIG_HAVE_CLK/]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle amdgpu_cgs_create_device() errors in amd_powerplay_create()Add error handling to propagate amdgpu_cgs_create_device() failuresto the caller. When amdgpu_cgs_create_device() fails, release hwmgrand return -ENOMEM to prevent null pointer dereference.[v1]->[v2]: Change error code from -EINVAL to -ENOMEM. Free hwmgr.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: debugfs hang_hws skip GPU with MESdebugfs hang_hws is used by GPU reset test with HWS, for MES this crashthe kernel with NULL pointer access because dqm->packet_mgr is not setupfor MES path.Skip GPU with MES for now, MES hang_hws debugfs interface will besupported later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37862 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: pidff: Fix null pointer dereference in pidff_find_fieldsThis function triggered a null pointer dereference if used to search fora report that isn't implemented on the device. This happened both foroptional and required reports alike.The same logic was applied to pidff_find_special_field and althoughpidff_init_fields should return an error earlier if one of the requiredreports is missing, future modifications could change this logic andresurface this possible null pointer dereference again.LKML bug report:https://lore.kernel.org/all/CAL-gK7f5=R0nrrQdPtaZZr1fd-cdAMbDMuZ_NLA8vM0SX+nGSw@mail.gmail.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37867 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Silence oversized kvmalloc() warningsyzkaller triggered an oversized kvmalloc() warning.Silence it by adding __GFP_NOWARN.syzkaller log: WARNING: CPU: 7 PID: 518 at mm/util.c:665 __kvmalloc_node_noprof+0x175/0x180 CPU: 7 UID: 0 PID: 518 Comm: c_repro Not tainted 6.11.0-rc6+ #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__kvmalloc_node_noprof+0x175/0x180 RSP: 0018:ffffc90001e67c10 EFLAGS: 00010246 RAX: 0000000000000100 RBX: 0000000000000400 RCX: ffffffff8149d46b RDX: 0000000000000000 RSI: ffff8881030fae80 RDI: 0000000000000002 RBP: 000000712c800000 R08: 0000000000000100 R09: 0000000000000000 R10: ffffc90001e67c10 R11: 0030ae0601000000 R12: 0000000000000000 R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000000 FS: 00007fde79159740(0000) GS:ffff88813bdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000180 CR3: 0000000105eb4005 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_umem_odp_get+0x1f6/0x390 mlx5_ib_reg_user_mr+0x1e8/0x450 ib_uverbs_reg_mr+0x28b/0x440 ib_uverbs_write+0x7d3/0xa30 vfs_write+0x1ac/0x6c0 ksys_write+0x134/0x170 ? __sanitizer_cov_trace_pc+0x1c/0x50 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37875 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:igc: fix PTM cycle trigger logicWriting to clear the PTM status 'valid' bit while the PTM cycle istriggered results in unreliable PTM operation. To fix this, clear thePTM 'trigger' and status after each PTM transaction.The issue can be reproduced with the following:$ sudo phc2sys -R 1000 -O 0 -i tsn0 -mNote: 1000 Hz (-R 1000) is unrealistically large, but provides a way toquickly reproduce the issue.PHC2SYS exits with:"ioctl PTP_OFFSET_PRECISE: Connection timed out" when the PTM transaction failsThis patch also fixes a hang in igc_probe() when loading the igcdriver in the kdump kernel on systems supporting PTM.The igc driver running in the base kernel enables PTM trigger inigc_probe(). Therefore the driver is always in PTM trigger mode,except in brief periods when manually triggering a PTM cycle.When a crash occurs, the NIC is reset while PTM trigger is enabled.Due to a hardware problem, the NIC is subsequently in a bad busmasterstate and doesn't handle register reads/writes. When runningigc_probe() in the kdump kernel, the first register access to a NICregister hangs driver probing and ultimately breaks kdump.With this patch, igc has PTM trigger disabled most of the time,and the trigger is only enabled for very brief (10 - 100 us) periodswhen manually triggering a PTM cycle. Chances that a crash occursduring a PTM trigger are not 0, but extremely reduced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37878 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Fix WARN_ON(!ctx) in __free_event() for partial initMove the get_ctx(child_ctx) call and the child_event->ctx assignment tooccur immediately after the child event is allocated. Ensure thatchild_event->ctx is non-NULL before any subsequent error path withininherit_event calls free_event(), satisfying the assumptions of thecleanup code.Details:There's no clear Fixes tag, because this bug is a side-effect ofmultiple interacting commits over time (up to 15 years old), nota single regression.The code initially incremented refcount then assigned contextimmediately after the child_event was created. Later, an earlyvalidity check for child_event was added before therefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check wasadded, assuming event->ctx is valid if the pmu_ctx is valid.The problem is that the WARN_ON_ONCE() could trigger after the initialcheck passed but before child_event->ctx was assigned, violating itsprecondition. The solution is to assign child_event->ctx right afterits initial validation. This ensures the context exists for anysubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().To resolve it, defer the refcount update and child_event->ctx assignmentdirectly after child_event->pmu_ctx is set but before checking if theparent event is orphaned. The cleanup routine depends onevent->pmu_ctx being non-NULL before it verifies event->ctx isnon-NULL. This also maintains the author's original intent of passingin child_ctx to find_get_pmu_context before its refcount/assignment.[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37879 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:9p/net: fix improper handling of bogus negative read/write repliesIn p9_client_write() and p9_client_read_once(), if the serverincorrectly replies with success but a negative write/read count then wewould consider written (negative) <= rsize (positive) because bothvariables were signed.Make variables unsigned to avoid this problem.The reproducer linked below now fails with the following error insteadof a null pointer deref:9pnet: bogus RWRITE count (4294967295 > 3)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37881 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: aspeed: Add NULL pointer check in ast_vhub_init_dev()The variable d->name, returned by devm_kasprintf(), could be NULL.A pointer check is added to prevent potential NULL pointer dereference.This is similar to the fix in commit 3027e7b15b02("ice: Fix some null pointer dereference issues in ice_ptp.c").This issue is found by our static analysis tool

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: qfq: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of qfq, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.This patch checks whether the class was already added to the agg->activelist (cl_is_active) before doing the addition to cater for the reentrantcase.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37914 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: ets: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of ets, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whetherthe class was already added to the active_list (cl_is_active) beforedoing the addition to cater for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37915 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: drr: Fix double list add in class with netem as child qdiscAs described in Gerrard's report [1], there are use cases where a netemchild qdisc will make the parent qdisc's enqueue callback reentrant.In the case of drr, there won't be a UAF, but the code will add the sameclassifier to the list twice, which will cause memory corruption.In addition to checking for qlen being zero, this patch checks whether theclass was already added to the active_list (cl_is_active) before addingto the list to cover for the reentrant case.[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: adjust subpage bit start based on sectorsizeWhen running machines with 64k page size and a 16k nodesize we startedseeing tree log corruption in production. This turned out to be becausewe were not writing out dirty blocks sometimes, so this in fact affectsall metadata writes.When writing out a subpage EB we scan the subpage bitmap for a dirtyrange. If the range isn't dirty we do bit_start++;to move onto the next bit. The problem is the bitmap is based on thenumber of sectors that an EB has. So in this case, we have a 64kpagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4bits for every node. With a 64k page size we end up with 4 nodes perpage.To make this easier this is how everything looks[0 16k 32k 48k ] logical address[0 4 8 12 ] radix tree offset[ 64k page ] folio[ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers[ | | | | | | | | | | | | | | | | ] bitmapNow we use all of our addressing based on fs_info->sectorsize_bits, soas you can see the above our 16k eb->start turns into radix entry 4.When we find a dirty range for our eb, we correctly do bit_start +=sectors_per_node, because if we start at bit 0, the next bit for thenext eb is 4, to correspond to eb->start 16k.However if our range is clean, we will do bit_start++, which will nowput us offset from our radix tree entries.In our case, assume that the first time we check the bitmap the block isnot dirty, we increment bit_start so now it == 1, and then we looparound and check again. This time it is dirty, and we go to find thatstart using the following equation start = folio_start + bit_start * fs_info->sectorsize;so in the case above, eb->start 0 is now dirty, and we calculate startas 0 + 1 * fs_info->sectorsize = 4096 4096 >> 12 = 1Now we're looking up the radix tree for 1, and we won't find an eb.What's worse is now we're using bit_start == 1, so we do bit_start +=sectors_per_node, which is now 5. If that eb is dirty we will run intothe same thing, we will look at an offset that is not populated in theradix tree, and now we're skipping the writeout of dirty extent buffers.The best fix for this is to not use sectorsize_bits to address nodes,but that's a larger change. Since this is a fs corruption problem fixit simply by always using sectors_per_node to increment the start bit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37937 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:objtool, media: dib8000: Prevent divide-by-zero in dib8000_set_dds()If dib8000_set_dds()'s call to dib8000_read32() returns zero, the resultis a divide-by-zero. Prevent that from happening.Fixes the following warning with an UBSAN kernel: drivers/media/dvb-frontends/dib8000.o: warning: objtool: dib8000_tune() falls through to next function dib8096p_cfg_DibRx()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37938 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Verify event formats that have "%*p.."The trace event verifier checks the formats of trace events to make surethat they do not point at memory that is not in the trace event itself orin data that will never be freed. If an event references data that wasallocated when the event triggered and that same data is freed before theevent is read, then the kernel can crash by reading freed memory.The verifier runs at boot up (or module load) and scans the print formatsof the events and checks their arguments to make sure that dereferencedpointers are safe. If the format uses "%*p.." the verifier will ignore it,and that could be dangerous. Cover this case as well.Also add to the sample code a use case of "%*pbl".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37940 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Add cond_resched() to ftrace_graph_set_hash()When the kernel contains a large number of functions that can be traced,the loop in ftrace_graph_set_hash() may take a lot of time to execute.This may trigger the softlockup watchdog.Add cond_resched() within the loop to allow the kernel to remainresponsive even when processing a large number of functions.This matches the cond_resched() that is used in other locations of thecode that iterates over all functions that can be traced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37945 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHYDSA has 2 kinds of drivers:1. Those who call dsa_switch_suspend() and dsa_switch_resume() from their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz2. Those who don't: all others. The above methods should be optional.For type 1, dsa_switch_suspend() calls dsa_user_suspend() -> phylink_stop(),and dsa_switch_resume() calls dsa_user_resume() -> phylink_start().These seem good candidates for setting mac_managed_pm = true becausethat is essentially its definition [1], but that does not seem to be thebiggest problem for now, and is not what this change focuses on.Talking strictly about the 2nd category of DSA drivers here (whichdo not have MAC managed PM, meaning that for their attached PHYs,mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),I have noticed that the following warning from mdio_bus_phy_resume() istriggered: WARN_ON(phydev->state != PHY_HALTED && phydev->state != PHY_READY && phydev->state != PHY_UP);because the PHY state machine is running.It's running as a result of a previous dsa_user_open() -> ... ->phylink_start() -> phy_start() having been initiated by the user.The previous mdio_bus_phy_suspend() was supposed to have calledphy_stop_machine(), but it didn't. So this is why the PHY is in statePHY_NOLINK by the time mdio_bus_phy_resume() runs.mdio_bus_phy_suspend() did not call phy_stop_machine() because forphylink, the phydev->adjust_link function pointer is NULL. This seems atechnicality introduced by commit fddd91016d16 ("phylib: fix PAL statemachine restart on resume"). That commit was written before phylinkexisted, and was intended to avoid crashing with consumer drivers whichdon't use the PHY state machine - phylink always does, when using a PHY.But phylink itself has historically not been developed withsuspend/resume in mind, and apparently not tested too much in thatscenario, allowing this bug to exist unnoticed for so long. Plus, priorto the WARN_ON(), it would have likely been invisible.This issue is not in fact restricted to type 2 DSA drivers (according tothe above ad-hoc classification), but can be extrapolated to any MACdriver with phylink and MDIO-bus-managed PHY PM ops. DSA is just wherethe issue was reported. Assuming mac_managed_pm is set correctly, aquick search indicates the following other drivers might be affected:$ grep -Zlr PHYLINK_NETDEV drivers/ | xargs -0 grep -L mac_managed_pmdrivers/net/ethernet/atheros/ag71xx.cdrivers/net/ethernet/microchip/sparx5/sparx5_main.cdrivers/net/ethernet/microchip/lan966x/lan966x_main.cdrivers/net/ethernet/freescale/dpaa2/dpaa2-mac.cdrivers/net/ethernet/freescale/fs_enet/fs_enet-main.cdrivers/net/ethernet/freescale/dpaa/dpaa_eth.cdrivers/net/ethernet/freescale/ucc_geth.cdrivers/net/ethernet/freescale/enetc/enetc_pf_common.cdrivers/net/ethernet/marvell/mvpp2/mvpp2_main.cdrivers/net/ethernet/marvell/mvneta.cdrivers/net/ethernet/marvell/prestera/prestera_main.cdrivers/net/ethernet/mediatek/mtk_eth_soc.cdrivers/net/ethernet/altera/altera_tse_main.cdrivers/net/ethernet/wangxun/txgbe/txgbe_phy.cdrivers/net/ethernet/meta/fbnic/fbnic_phylink.cdrivers/net/ethernet/tehuti/tn40_phy.cdrivers/net/ethernet/mscc/ocelot_net.cMake the existing conditions dependent on the PHY device having aphydev->phy_link_change() implementation equal to the defaultphy_link_change() provided by phylib. Otherwise, we implicitly know thatthe phydev has the phylink-provided phylink_phy_change() callback, andwhen phylink is used, the PHY state machine always needs to be stopped/started on the suspend/resume path. The code is structured as such thatif phydev->phy_link_change() is absent, it is a matter of time until thekernel will crash - no need to further complicate the test.Thus, for the situation where the PM is not managed b---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37949 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xenbus: Use kref to track req lifetimeMarek reported seeing a NULL pointer fault in the xenbus_threadcallstack:BUG: kernel NULL pointer dereference, address: 0000000000000000RIP: e030:__wake_up_common+0x4c/0x180Call Trace: __wake_up_common_lock+0x82/0xd0 process_msg+0x18e/0x2f0 xenbus_thread+0x165/0x1c0process_msg+0x18e is req->cb(req). req->cb is set to xs_wake_up(), athin wrapper around wake_up(), or xenbus_dev_queue_reply(). It seemslike it was xs_wake_up() in this case.It seems like req may have woken up the xs_wait_for_reply(), whichkfree()ed the req. When xenbus_thread resumes, it faults on the zero-eddata.Linux Device Drivers 2nd edition states:"Normally, a wake_up call can cause an immediate reschedule to happen,meaning that other processes might run before wake_up returns."... which would match the behaviour observed.Change to keeping two krefs on each request. One for the caller, andone for xenbus_thread. Each will kref_put() when finished, and the lastwill free it.This use of kref matches the description inDocumentation/core-api/kref.rst

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37957 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Forcibly leave SMM mode on SHUTDOWN interceptionPreviously, commit ed129ec9057f ("KVM: x86: forcibly leave nested modeon vCPU reset") addressed an issue where a triple fault occurring innested mode could lead to use-after-free scenarios. However, the commitdid not handle the analogous situation for System Management Mode (SMM).This omission results in triggering a WARN when KVM forces a vCPU INITafter SHUTDOWN interception while the vCPU is in SMM. This situation wasreprodused using Syzkaller by: 1) Creating a KVM VM and vCPU 2) Sending a KVM_SMI ioctl to explicitly enter SMM 3) Executing invalid instructions causing consecutive exceptions and eventually a triple faultThe issue manifests as follows: WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112 kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Modules linked in: CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted 6.1.130-syzkaller-00157-g164fe5dde9b6 #0 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112 Call Trace: shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136 svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395 svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457 vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline] vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062 kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283 kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Architecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()in kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improperemulation of INIT. SHUTDOWN on SVM is a weird edge case where KVM needs todo _something_ sane with the VMCB, since it's technically undefined, andINIT is the least awful choice given KVM's ABI.So, double down on stuffing INIT on SHUTDOWN, and force the vCPU out ofSMM to avoid any weirdness (and the WARN).Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[sean: massage changelog, make it clear this isn't architectural behavior]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37959 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Scrub packet on bpf_redirect_peerWhen bpf_redirect_peer is used to redirect packets to a device inanother network namespace, the skb isn't scrubbed. That can lead skbinformation from one namespace to be "misused" in another namespace.As one example, this is causing Cilium to drop traffic when usingbpf_redirect_peer to redirect packets that just went through IPsecdecryption to a container namespace. The following pwru trace shows (1)the packet path from the host's XFRM layer to the container's XFRMlayer where it's dropped and (2) the number of active skb extensions ateach function. NETNS MARK IFACE TUPLE FUNC 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 xfrm4_rcv_cb .active_extensions = (__u8)2, 4026533547 d00 eth0 10.244.3.124:35473->10.244.2.158:53 gro_cells_receive .active_extensions = (__u8)2, [...] 4026533547 0 eth0 10.244.3.124:35473->10.244.2.158:53 skb_do_redirect .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 ip_rcv_core .active_extensions = (__u8)2, [...] 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 udp_queue_rcv_one_skb .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_policy_check .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 __xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 security_xfrm_decode_session .active_extensions = (__u8)2, 4026534999 0 eth0 10.244.3.124:35473->10.244.2.158:53 kfree_skb_reason(SKB_DROP_REASON_XFRM_POLICY) .active_extensions = (__u8)2,In this case, there are no XFRM policies in the container's networknamespace so the drop is unexpected. When we decrypt the IPsec packet,the XFRM state used for decryption is set in the skb extensions. Thisinformation is preserved across the netns switch. When we reach theXFRM policy check in the container's netns, __xfrm_policy_check dropsthe packet with LINUX_MIB_XFRMINNOPOLS because a (container-side) XFRMpolicy can't be found that matches the (host-side) XFRM state used fordecryption.This patch fixes this by scrubbing the packet when usingbpf_redirect_peer, as is done on typical netns switches via vethdevices except skb->mark and skb->tstamp are not zeroed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37961 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipvs: fix uninit-value for saddr in do_output_route4syzbot reports for uninit-value for the saddr argument [1].commit 4754957f04f5 ("ipvs: do not use random local source address fortunnels") already implies that the input value of saddrshould be ignored but the code is still reading it which can preventto connect the route. Fix it by changing the argument to ret_saddr.[1]BUG: KMSAN: uninit-value in do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 do_output_route4+0x42c/0x4d0 net/netfilter/ipvs/ip_vs_xmit.c:147 __ip_vs_get_out_rt+0x403/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:330 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eUninit was created at: slab_post_alloc_hook mm/slub.c:4167 [inline] slab_alloc_node mm/slub.c:4210 [inline] __kmalloc_cache_noprof+0x8fa/0xe00 mm/slub.c:4367 kmalloc_noprof include/linux/slab.h:905 [inline] ip_vs_dest_dst_alloc net/netfilter/ipvs/ip_vs_xmit.c:61 [inline] __ip_vs_get_out_rt+0x35d/0x21d0 net/netfilter/ipvs/ip_vs_xmit.c:323 ip_vs_tunnel_xmit+0x205/0x2380 net/netfilter/ipvs/ip_vs_xmit.c:1136 ip_vs_in_hook+0x1aa5/0x35b0 net/netfilter/ipvs/ip_vs_core.c:2063 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf7/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] __ip_local_out+0x758/0x7e0 net/ipv4/ip_output.c:118 ip_local_out net/ipv4/ip_output.c:127 [inline] ip_send_skb+0x6a/0x3c0 net/ipv4/ip_output.c:1501 udp_send_skb+0xfda/0x1b70 net/ipv4/udp.c:1195 udp_sendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inet_sendmsg+0x1fc/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x267/0x380 net/socket.c:727 ____sys_sendmsg+0x91b/0xda0 net/socket.c:2566 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2620 __sys_sendmmsg+0x41d/0x880 net/socket.c:2702 __compat_sys_sendmmsg net/compat.c:360 [inline] __do_compat_sys_sendmmsg net/compat.c:367 [inline] __se_compat_sys_sendmmsg net/compat.c:364 [inline] __ia32_compat_sys_sendmmsg+0xc8/0x140 net/compat.c:364 ia32_sys_call+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls_32.h:346 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline] __do_fast_syscall_32+0xb0/0x110 arch/x86/entry/syscall_32.c:306 do_fast_syscall_32+0x38/0x80 arch/x86/entry/syscall_32.c:331 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/syscall_32.c:369 entry_SYSENTER_compat_after_hwframe+0x84/0x8eCPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef)Hardware name: Google Google Compute Engi---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37967 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix deadlockThis patch introduces the ucsi_con_mutex_lock / ucsi_con_mutex_unlockfunctions to the UCSI driver. ucsi_con_mutex_lock ensures the connectormutex is only locked if a connection is established and the partner pointeris valid. This resolves a deadlock scenario whereucsi_displayport_remove_partner holds con->mutex waiting fordp_altmode_work to complete while dp_altmode_work attempts to acquire it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37968 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: opt3001: fix deadlock due to concurrent flag accessThe threaded IRQ function in this driver is reading the flag twice: once tolock a mutex and once to unlock it. Even though the code setting the flagis designed to prevent it, there are subtle cases where the flag could betrue at the mutex_lock stage and false at the mutex_unlock stage. Thisresults in the mutex not being unlocked, resulting in a deadlock.Fix it by making the opt3001_irq() code generally more robust, reading theflag into a variable and using the variable value at both stages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37969 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_tagged_fifoPrevent st_lsm6dsx_read_tagged_fifo from falling in an infinite loop incase pattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37970 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: st_lsm6dsx: fix possible lockup in st_lsm6dsx_read_fifoPrevent st_lsm6dsx_read_fifo from falling in an infinite loop in casepattern_len is equal to zero and the device FIFO is not empty.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37980 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix resource leak in blk_register_queue() error pathWhen registering a queue fails after blk_mq_sysfs_register() issuccessful but the function later encounters an error, we needto clean up the blk_mq_sysfs resources.Add the missing blk_mq_sysfs_unregister() call in the error pathto properly clean up these resources and prevent a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37982 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: wl1251: fix memory leak in wl1251_tx_workThe skb dequeued from tx_queue is lost when wl1251_ps_elp_wakeup failswith a -ETIMEDOUT error. Fix that by queueing the skb back to tx_queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37985 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:USB: wdm: close race between wdm_open and wdm_wwan_port_stopClearing WDM_WWAN_IN_USE must be the last action orwe can open a chardev whose URBs are still poisoned

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: phy: leds: fix memory leakA network restart test on a router led to an out-of-memory condition,which was traced to a memory leak in the PHY LED trigger code.The root cause is misuse of the devm API. The registration function(phy_led_triggers_register) is called from phy_attach_direct, notphy_probe, and the unregister function (phy_led_triggers_unregister)is called from phy_detach, not phy_remove. This means the register andunregister functions can be called multiple times for the same PHYdevice, but devm-allocated memory is not freed until the driver isunbound.This also prevents kmemleak from detecting the leak, as the devm APIinternally stores the allocated pointer.Fix this by replacing devm_kzalloc/devm_kcalloc with standardkzalloc/kcalloc, and add the corresponding kfree calls in the unregisterpath.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcm80211: fmac: Add error handling for brcmf_usb_dl_writeimage()The function brcmf_usb_dl_writeimage() calls the functionbrcmf_usb_dl_cmd() but dose not check its return value. The'state.state' and the 'state.bytes' are uninitialized if thefunction brcmf_usb_dl_cmd() fails. It is dangerous to useuninitialized variables in the conditions.Add error handling for brcmf_usb_dl_cmd() to jump to errorhandling path if the brcmf_usb_dl_cmd() fails and the'state.state' and the 'state.bytes' are uninitialized.Improve the error message to report more detailed errorinformation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37992 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: Flush gso_skb list too during ->change()Previously, when reducing a qdisc's limit via the ->change() operation, onlythe main skb queue was trimmed, potentially leaving packets in the gso_skblist. This could result in NULL pointer dereference when we only checksch->limit against sch->q.qlen.This patch introduces a new helper, qdisc_dequeue_internal(), which ensuresboth the gso_skb list and the main queue are properly flushed when trimmingexcess packets. All relevant qdiscs (codel, fq, fq_codel, fq_pie, hhf, pie)are updated to use this helper in their ->change() routines.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37995 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:module: ensure that kobject_put() is safe for module type kobjectsIn 'lookup_or_create_module_kobject()', an internal kobject is createdusing 'module_ktype'. So call to 'kobject_put()' on error handlingpath causes an attempt to use an uninitialized completion pointer in'module_kobject_release()'. In this scenario, we just want to releasekobject without an extra synchronization required for a regular moduleunloading process, so adding an extra check whether 'complete()' isactually required makes 'kobject_put()' safe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38023 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs: handle failure of nfs_get_lock_context in unlock pathWhen memory is insufficient, the allocation of nfs_lock_context innfs_get_lock_context() fails and returns -ENOMEM. If we mistakenly treatan nfs4_unlockdata structure (whose l_ctx member has been set to -ENOMEM)as valid and proceed to execute rpc_run_task(), this will trigger a NULLpointer dereference in nfs4_locku_prepare. For example:BUG: kernel NULL pointer dereference, address: 000000000000000cPGD 0 P4D 0Oops: Oops: 0000 [#1] SMP PTICPU: 15 UID: 0 PID: 12 Comm: kworker/u64:0 Not tainted 6.15.0-rc2-dirty #60Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40Workqueue: rpciod rpc_async_scheduleRIP: 0010:nfs4_locku_prepare+0x35/0xc2Code: 89 f2 48 89 fd 48 c7 c7 68 69 ef b5 53 48 8b 8e 90 00 00 00 48 89 f3RSP: 0018:ffffbbafc006bdb8 EFLAGS: 00010246RAX: 000000000000004b RBX: ffff9b964fc1fa00 RCX: 0000000000000000RDX: 0000000000000000 RSI: fffffffffffffff4 RDI: ffff9ba53fddbf40RBP: ffff9ba539934000 R08: 0000000000000000 R09: ffffbbafc006bc38R10: ffffffffb6b689c8 R11: 0000000000000003 R12: ffff9ba539934030R13: 0000000000000001 R14: 0000000004248060 R15: ffffffffb56d1c30FS: 0000000000000000(0000) GS:ffff9ba5881f0000(0000) knlGS:00000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000000c CR3: 000000093f244000 CR4: 00000000000006f0Call Trace: __rpc_execute+0xbc/0x480 rpc_async_schedule+0x2f/0x40 process_one_work+0x232/0x5d0 worker_thread+0x1da/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x10d/0x240 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Modules linked in:CR2: 000000000000000c---[ end trace 0000000000000000 ]---Free the allocated nfs4_unlockdata when nfs_get_lock_context() fails andreturn NULL to terminate subsequent rpc_run_task, preventing NULL pointerdereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bugCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xcf/0x610 mm/kasan/report.c:489 kasan_report+0xb5/0xe0 mm/kasan/report.c:602 rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195 rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132 __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232 rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109 create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052 ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095 ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679 vfs_write fs/read_write.c:677 [inline] vfs_write+0x26a/0xcc0 fs/read_write.c:659 ksys_write+0x1b8/0x200 fs/read_write.c:731 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fIn the function rxe_create_cq, when rxe_cq_from_init fails, the functionrxe_cleanup will be called to handle the allocated resources. In fact,some memory resources have already been freed in the functionrxe_cq_from_init. Thus, this problem will occur.The solution is to let rxe_cleanup do all the work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix use-after-free in cifs_fill_direntThere is a race condition in the readdir concurrency process, which mayaccess the rsp buffer after it has been released, triggering thefollowing KASAN warning. ================================================================== BUG: KASAN: slab-use-after-free in cifs_fill_dirent+0xb03/0xb60 [cifs] Read of size 4 at addr ffff8880099b819c by task a.out/342975 CPU: 2 UID: 0 PID: 342975 Comm: a.out Not tainted 6.15.0-rc6+ #240 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: dump_stack_lvl+0x53/0x70 print_report+0xce/0x640 kasan_report+0xb8/0xf0 cifs_fill_dirent+0xb03/0xb60 [cifs] cifs_readdir+0x12cb/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f996f64b9f9 Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 0d f7 c3 0c 00 f7 d8 64 89 8 RSP: 002b:00007f996f53de78 EFLAGS: 00000207 ORIG_RAX: 000000000000004e RAX: ffffffffffffffda RBX: 00007f996f53ecdc RCX: 00007f996f64b9f9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007f996f53dea0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000207 R12: ffffffffffffff88 R13: 0000000000000000 R14: 00007ffc8cd9a500 R15: 00007f996f51e000 Allocated by task 408: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 __kasan_slab_alloc+0x6e/0x70 kmem_cache_alloc_noprof+0x117/0x3d0 mempool_alloc_noprof+0xf2/0x2c0 cifs_buf_get+0x36/0x80 [cifs] allocate_buffers+0x1d2/0x330 [cifs] cifs_demultiplex_thread+0x22b/0x2690 [cifs] kthread+0x394/0x720 ret_from_fork+0x34/0x70 ret_from_fork_asm+0x1a/0x30 Freed by task 342979: kasan_save_stack+0x20/0x40 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x37/0x50 kmem_cache_free+0x2b8/0x500 cifs_buf_release+0x3c/0x70 [cifs] cifs_readdir+0x1c97/0x3190 [cifs] iterate_dir+0x1a1/0x520 __x64_sys_getdents64+0x134/0x220 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e The buggy address belongs to the object at ffff8880099b8000 which belongs to the cache cifs_request of size 16588 The buggy address is located 412 bytes inside of freed 16588-byte region [ffff8880099b8000, ffff8880099bc0cc) The buggy address belongs to the physical page: page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x99b8 head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 anon flags: 0x80000000000040(head|node=0|zone=1) page_type: f5(slab) raw: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 raw: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000040 ffff888001e03400 0000000000000000 dead000000000001 head: 0000000000000000 0000000000010001 00000000f5000000 0000000000000000 head: 0080000000000003 ffffea0000266e01 00000000ffffffff 00000000ffffffff head: ffffffffffffffff 0000000000000000 00000000ffffffff 0000000000000008 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880099b8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff8880099b8180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8880099b8200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880099b8280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ==================================================================POC is available in the link [1].The problem triggering process is as follows:Process 1 Process 2--------------------------------------truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38052 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/tipc: fix slab-use-after-free Read in tipc_aead_encrypt_doneSyzbot reported a slab-use-after-free with the following call trace: ================================================================== BUG: KASAN: slab-use-after-free in tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 Read of size 8 at addr ffff88807a733000 by task kworker/1:0/25 Call Trace: kasan_report+0xd9/0x110 mm/kasan/report.c:601 tipc_aead_encrypt_done+0x4bd/0x510 net/tipc/crypto.c:840 crypto_request_complete include/crypto/algapi.h:266 aead_request_complete include/crypto/internal/aead.h:85 cryptd_aead_crypt+0x3b8/0x750 crypto/cryptd.c:772 crypto_request_complete include/crypto/algapi.h:266 cryptd_queue_worker+0x131/0x200 crypto/cryptd.c:181 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231 Allocated by task 8355: kzalloc_noprof include/linux/slab.h:778 tipc_crypto_start+0xcc/0x9e0 net/tipc/crypto.c:1466 tipc_init_net+0x2dd/0x430 net/tipc/core.c:72 ops_init+0xb9/0x650 net/core/net_namespace.c:139 setup_net+0x435/0xb40 net/core/net_namespace.c:343 copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508 create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110 unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:228 ksys_unshare+0x419/0x970 kernel/fork.c:3323 __do_sys_unshare kernel/fork.c:3394 Freed by task 63: kfree+0x12a/0x3b0 mm/slub.c:4557 tipc_crypto_stop+0x23c/0x500 net/tipc/crypto.c:1539 tipc_exit_net+0x8c/0x110 net/tipc/core.c:119 ops_exit_list+0xb0/0x180 net/core/net_namespace.c:173 cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640 process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231After freed the tipc_crypto tx by delete namespace, tipc_aead_encrypt_donemay still visit it in cryptd_queue_worker workqueue.I reproduce this issue by: ip netns add ns1 ip link add veth1 type veth peer name veth2 ip link set veth1 netns ns1 ip netns exec ns1 tipc bearer enable media eth dev veth1 ip netns exec ns1 tipc node set key this_is_a_master_key master ip netns exec ns1 tipc bearer disable media eth dev veth1 ip netns del ns1The key of reproduction is that, simd_aead_encrypt is interrupted, leadingto crypto_simd_usable() return false. Thus, the cryptd_queue_worker istriggered, and the tipc_crypto tx will be visited. tipc_disc_timeout tipc_bearer_xmit_skb tipc_crypto_xmit tipc_aead_encrypt crypto_aead_encrypt // encrypt() simd_aead_encrypt // crypto_simd_usable() is false child = &ctx->cryptd_tfm->base; simd_aead_encrypt crypto_aead_encrypt // encrypt() cryptd_aead_encrypt_enqueue cryptd_aead_enqueue cryptd_enqueue_request // trigger cryptd_queue_worker queue_work_on(smp_processor_id(), cryptd_wq, &cpu_queue->work)Fix this by holding net reference count before encrypt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix null-ptr-deref in idpf_features_checkidpf_features_check is used to validate the TX packet. skb headerlength is compared with the hardware supported value received fromthe device control plane. The value is stored in the adapter structureand to access it, vport pointer is used. During reset all the vportsare released and the vport pointer that the netdev private structurepoints to is NULL.To avoid null-ptr-deref, store the max header length value in netdevprivate structure. This also helps to cache the value and avoidaccessing adapter pointer in hot path.BUG: kernel NULL pointer dereference, address: 0000000000000068...RIP: 0010:idpf_features_check+0x6d/0xe0 [idpf]Call Trace: ? __die+0x23/0x70 ? page_fault_oops+0x154/0x520 ? exc_page_fault+0x76/0x190 ? asm_exc_page_fault+0x26/0x30 ? idpf_features_check+0x6d/0xe0 [idpf] netif_skb_features+0x88/0x310 validate_xmit_skb+0x2a/0x2b0 validate_xmit_skb_list+0x4c/0x70 sch_direct_xmit+0x19d/0x3a0 __dev_queue_xmit+0xb74/0xe70 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38057 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: fix skb leaksA few error paths are missing a kfree_skb.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38072 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libnvdimm/labels: Fix divide error in nd_label_data_init()If a faulty CXL memory device returns a broken zero LSA size in itsmemory device information (Identify Memory Device (Opcode 4000h), CXLspec. 3.1, 8.2.9.9.1.1), a divide error occurs in the libnvdimmdriver: Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:nd_label_data_init+0x10e/0x800 [libnvdimm]Code and flow:1) CXL Command 4000h returns LSA size = 02) config_size is assigned to zero LSA size (CXL pmem driver):drivers/cxl/pmem.c: .config_size = mds->lsa_size,3) max_xfer is set to zero (nvdimm driver):drivers/nvdimm/label.c: max_xfer = min_t(size_t, ndd->nsarea.max_xfer, config_size);4) A subsequent DIV_ROUND_UP() causes a division by zero:drivers/nvdimm/label.c: /* Make our initial read size a multiple of max_xfer size */drivers/nvdimm/label.c: read_size = min(DIV_ROUND_UP(read_size, max_xfer) * max_xfer,drivers/nvdimm/label.c- config_size);Fix this by checking the config size parameter by extending anexisting check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Avoid buffer overflow in current_password_store()If the 'buf' array received from the user contains an empty string, the'length' variable will be zero. Accessing the 'buf' array element withindex 'length - 1' will result in a buffer overflow.Add a check for an empty string.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix race of buffer access at PCM OSS layerThe PCM OSS layer tries to clear the buffer with the silence data atinitialization (or reconfiguration) of a stream with the explicit callof snd_pcm_format_set_silence() with runtime->dma_area. But this maylead to a UAF because the accessed runtime->dma_area might be freedconcurrently, as it's performed outside the PCM ops.For avoiding it, move the code into the PCM core and perform it insidethe buffer access lock, so that it won't be changed during theoperation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38094 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: cadence: macb: Fix a possible deadlock in macb_halt_tx.There is a situation where after THALT is set high, TGO stays high aswell. Because jiffies are never updated, as we are in a context withinterrupts disabled, we never exit that loop and have a deadlock.That deadlock was noticed on a sama5d4 device that stayed locked for days.Use retries instead of jiffies so that the timeout really works and we donot have a deadlock anymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dma-buf: insert memory barrier before updating num_fencessmp_store_mb() inserts memory barrier after storing operation.It is different with what the comment is originally aiming so Nullpointer dereference can be happened if memory update is reordered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38096 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: don't warn when if there is a FW erroriwl_trans_reclaim is warning if it is called when the FW is not alive.But if it is called when there is a pending restart, i.e. after a FWerror, there is no need to warn, instead - return silently.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38115 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: sch_sfq: fix a potential crash on gso_skb handlingSFQ has an assumption of always being able to queue at least one packet.However, after the blamed commit, sch->q.len can be inflated by packetsin sch->gso_skb, and an enqueue() on an empty SFQ qdisc can be followedby an immediate drop.Fix sfq_drop() to properly clear q->tail in this situation.ip netns add lbip link add dev to-lb type veth peer name in-lb netns lbethtool -K to-lb tso off # force qdisc to requeue gso_skbip netns exec lb ethtool -K in-lb gro on # enable NAPIip link set dev to-lb upip -netns lb link set dev in-lb upip addr add dev to-lb 192.168.20.1/24ip -netns lb addr add dev in-lb 192.168.20.2/24tc qdisc replace dev to-lb root sfq limit 100ip netns exec lb netservernetperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &netperf -H 192.168.20.2 -l 100 &

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38119 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: core: ufs: Fix a hang in the error handlerufshcd_err_handling_prepare() calls ufshcd_rpm_get_sync(). The latterfunction can only succeed if UFSHCD_EH_IN_PROGRESS is not set becauseresuming involves submitting a SCSI command and ufshcd_queuecommand()returns SCSI_MLQUEUE_HOST_BUSY if UFSHCD_EH_IN_PROGRESS is set. Fix thishang by setting UFSHCD_EH_IN_PROGRESS after ufshcd_rpm_get_sync() hasbeen called instead of before.Backtrace:__switch_to+0x174/0x338__schedule+0x600/0x9e4schedule+0x7c/0xe8schedule_timeout+0xa4/0x1c8io_schedule_timeout+0x48/0x70wait_for_common_io+0xa8/0x160 //waiting on START_STOPwait_for_completion_io_timeout+0x10/0x20blk_execute_rq+0xe4/0x1e4scsi_execute_cmd+0x108/0x244ufshcd_set_dev_pwr_mode+0xe8/0x250__ufshcd_wl_resume+0x94/0x354ufshcd_wl_runtime_resume+0x3c/0x174scsi_runtime_resume+0x64/0xa4rpm_resume+0x15c/0xa1c__pm_runtime_resume+0x4c/0x90 // Runtime resume ongoingufshcd_err_handler+0x1a0/0xd08process_one_work+0x174/0x808worker_thread+0x15c/0x490kthread+0xf4/0x1ecret_from_fork+0x10/0x20[ bvanassche: rewrote patch description ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38122 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: add missing NULL check for gve_alloc_pending_packet() in TX DQOgve_alloc_pending_packet() can return NULL, but gve_tx_add_skb_dqo()did not check for this case before dereferencing the returned pointer.Add a missing NULL check to prevent a potential NULL pointerdereference when allocation fails.This improves robustness in low-memory scenarios.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38127 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix Tx scheduler error handling in XDP callbackWhen the XDP program is loaded, the XDP callback adds new Tx queues.This means that the callback must update the Tx scheduler with the newqueue number. In the event of a Tx scheduler failure, the XDP callbackshould also fail and roll back any changes previously made for XDPpreparation.The previous implementation had a bug that not all changes made by theXDP callback were rolled back. This caused the crash with the followingcall trace:[ +9.549584] ice 0000:ca:00.0: Failed VSI LAN queue config for XDP, error: -5[ +0.382335] Oops: general protection fault, probably for non-canonical address 0x50a2250a90495525: 0000 [#1] SMP NOPTI[ +0.010710] CPU: 103 UID: 0 PID: 0 Comm: swapper/103 Not tainted 6.14.0-net-next-mar-31+ #14 PREEMPT(voluntary)[ +0.010175] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022[ +0.010946] RIP: 0010:__ice_update_sample+0x39/0xe0 [ice][...][ +0.002715] Call Trace:[ +0.002452] [ +0.002021] ? __die_body.cold+0x19/0x29[ +0.003922] ? die_addr+0x3c/0x60[ +0.003319] ? exc_general_protection+0x17c/0x400[ +0.004707] ? asm_exc_general_protection+0x26/0x30[ +0.004879] ? __ice_update_sample+0x39/0xe0 [ice][ +0.004835] ice_napi_poll+0x665/0x680 [ice][ +0.004320] __napi_poll+0x28/0x190[ +0.003500] net_rx_action+0x198/0x360[ +0.003752] ? update_rq_clock+0x39/0x220[ +0.004013] handle_softirqs+0xf1/0x340[ +0.003840] ? sched_clock_cpu+0xf/0x1f0[ +0.003925] __irq_exit_rcu+0xc2/0xe0[ +0.003665] common_interrupt+0x85/0xa0[ +0.003839] [ +0.002098] [ +0.002106] asm_common_interrupt+0x26/0x40[ +0.004184] RIP: 0010:cpuidle_enter_state+0xd3/0x690Fix this by performing the missing unmapping of XDP queues fromq_vectors and setting the XDP rings pointer back to NULL after all thosequeues are released.Also, add an immediate exit from the XDP callback in case of ringpreparation failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38138 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: Add NULL check in udma_probe()devm_kasprintf() returns NULL when memory allocation fails. Currently,udma_probe() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38143 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:backlight: pm8941: Add NULL check in wled_configure()devm_kasprintf() returns NULL when memory allocation fails. Currently,wled_configure() does not check for this case, which results in a NULLpointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38145 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: Add NULL check in aspeed_lpc_enable_snoop()devm_kasprintf() returns NULL when memory allocation fails. Currently,aspeed_lpc_enable_snoop() does not check for this case, which results in aNULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.[arj: Fix Fixes: tag to use subject from 3772e5da4454]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38147 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: Don't call calipso functions for AF_INET sk.syzkaller reported a null-ptr-deref in txopt_get(). [0]The offset 0x70 was of struct ipv6_txoptions in struct ipv6_pinfo,so struct ipv6_pinfo was NULL there.However, this never happens for IPv6 sockets as inet_sk(sk)->pinet6is always set in inet6_create(), meaning the socket was not IPv6 one.The root cause is missing validation in netlbl_conn_setattr().netlbl_conn_setattr() switches branches based on structsockaddr.sa_family, which is passed from userspace. However,netlbl_conn_setattr() does not check if the address family matchesthe socket.The syzkaller must have called connect() for an IPv6 address onan IPv4 socket.We have a proper validation in tcp_v[46]_connect(), butsecurity_socket_connect() is called in the earlier stage.Let's copy the validation to netlbl_conn_setattr().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 2 UID: 0 PID: 12928 Comm: syz.9.1677 Not tainted 6.12.0 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:txopt_get include/net/ipv6.h:390 [inline]RIP: 0010:Code: 02 00 00 49 8b ac 24 f8 02 00 00 e8 84 69 2a fd e8 ff 00 16 fd 48 8d 7d 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 53 02 00 00 48 8b 6d 70 48 85 ed 0f 84 ab 01 00RSP: 0018:ffff88811b8afc48 EFLAGS: 00010212RAX: dffffc0000000000 RBX: 1ffff11023715f8a RCX: ffffffff841ab00cRDX: 000000000000000e RSI: ffffc90007d9e000 RDI: 0000000000000070RBP: 0000000000000000 R08: ffffed1023715f9d R09: ffffed1023715f9eR10: ffffed1023715f9d R11: 0000000000000003 R12: ffff888123075f00R13: ffff88810245bd80 R14: ffff888113646780 R15: ffff888100578a80FS: 00007f9019bd7640(0000) GS:ffff8882d2d00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f901b927bac CR3: 0000000104788003 CR4: 0000000000770ef0PKRU: 80000000Call Trace: calipso_sock_setattr+0x56/0x80 net/netlabel/netlabel_calipso.c:557 netlbl_conn_setattr+0x10c/0x280 net/netlabel/netlabel_kapi.c:1177 selinux_netlbl_socket_connect_helper+0xd3/0x1b0 security/selinux/netlabel.c:569 selinux_netlbl_socket_connect_locked security/selinux/netlabel.c:597 [inline] selinux_netlbl_socket_connect+0xb6/0x100 security/selinux/netlabel.c:615 selinux_socket_connect+0x5f/0x80 security/selinux/hooks.c:4931 security_socket_connect+0x50/0xa0 security/security.c:4598 __sys_connect_file+0xa4/0x190 net/socket.c:2067 __sys_connect+0x12c/0x170 net/socket.c:2088 __do_sys_connect net/socket.c:2098 [inline] __se_sys_connect net/socket.c:2095 [inline] __x64_sys_connect+0x73/0xb0 net/socket.c:2095 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f901b61a12dCode: 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f9019bd6fa8 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f901b925fa0 RCX: 00007f901b61a12dRDX: 000000000000001c RSI: 0000200000000140 RDI: 0000000000000003RBP: 00007f901b701505 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f901b5b62a0 R15: 00007f9019bb7000 Modules linked in:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38160 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()devm_kasprintf() returns NULL when memory allocation fails. Currently,raspberrypi_clk_register() does not check for this case, which resultsin a NULL pointer dereference.Add NULL check after devm_kasprintf() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Free invalid length skb in atmtcp_c_send().syzbot reported the splat below. [0]vcc_sendmsg() copies data passed from userspace to skb and passesit to vcc->dev->ops->send().atmtcp_c_send() accesses skb->data as struct atmtcp_hdr afterchecking if skb->len is 0, but it's not enough.Also, when skb->len == 0, skb and sk (vcc) were leaked becausedev_kfree_skb() is not called and sk_wmem_alloc adjustment is missingto revert atm_account_tx() in vcc_sendmsg(), which is expectedto be done in atm_pop_raw().Let's properly free skb with an invalid length in atmtcp_c_send().[0]:BUG: KMSAN: uninit-value in atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 atmtcp_c_send+0x255/0xed0 drivers/atm/atmtcp.c:294 vcc_sendmsg+0xd7c/0xff0 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fUninit was created at: slab_post_alloc_hook mm/slub.c:4154 [inline] slab_alloc_node mm/slub.c:4197 [inline] kmem_cache_alloc_node_noprof+0x818/0xf00 mm/slub.c:4249 kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:579 __alloc_skb+0x347/0x7d0 net/core/skbuff.c:670 alloc_skb include/linux/skbuff.h:1336 [inline] vcc_sendmsg+0xb40/0xff0 net/atm/common.c:628 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x330/0x3d0 net/socket.c:727 ____sys_sendmsg+0x7e0/0xd80 net/socket.c:2566 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2620 __sys_sendmsg net/socket.c:2652 [inline] __do_sys_sendmsg net/socket.c:2657 [inline] __se_sys_sendmsg net/socket.c:2655 [inline] __x64_sys_sendmsg+0x211/0x3e0 net/socket.c:2655 x64_sys_call+0x32fb/0x3db0 arch/x86/include/generated/asm/syscalls_64.h:47 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fCPU: 1 UID: 0 PID: 5798 Comm: syz-executor192 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(undef)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Revert atm_account_tx() if copy_from_iter_full() fails.In vcc_sendmsg(), we account skb->truesize to sk->sk_wmem_alloc byatm_account_tx().It is expected to be reverted by atm_pop_raw() later called byvcc->dev->ops->send(vcc, skb).However, vcc_sendmsg() misses the same revert when copy_from_iter_full()fails, and then we will leak a socket.Let's factorise the revert part as atm_return_tx() and call it inthe failure path.Note that the corresponding sk_wmem_alloc operation can be found inalloc_tx() as of the blamed commit. $ git blame -L:alloc_tx net/atm/common.c c55fa3cccbc2c~

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38198 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbcon: Make sure modelist not set on unregistered consoleIt looks like attempting to write to the "store_modes" sysfs node willrun afoul of unregistered consoles:UBSAN: array-index-out-of-bounds in drivers/video/fbdev/core/fbcon.c:122:28index -1 is out of range for type 'fb_info *[32]'... fbcon_info_from_console+0x192/0x1a0 drivers/video/fbdev/core/fbcon.c:122 fbcon_new_modelist+0xbf/0x2d0 drivers/video/fbdev/core/fbcon.c:3048 fb_new_modelist+0x328/0x440 drivers/video/fbdev/core/fbmem.c:673 store_modes+0x1c9/0x3e0 drivers/video/fbdev/core/fbsysfs.c:113 dev_attr_store+0x55/0x80 drivers/base/core.c:2439static struct fb_info *fbcon_registered_fb[FB_MAX];...static signed char con2fb_map[MAX_NR_CONSOLES];...static struct fb_info *fbcon_info_from_console(int console)... return fbcon_registered_fb[con2fb_map[console]];If con2fb_map contains a -1 things go wrong here. Instead, return NULL,as callers of fbcon_info_from_console() are trying to compare againstexisting "info" pointers, so error handling should kick in correctly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: clamp maximum map bucket size to INT_MAXOtherwise, it is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof()when resizing hashtable because __GFP_NOWARN is unset.Similar to: b541ba7d1f5a ("netfilter: conntrack: clamp maximum hashtable size to INT_MAX")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38208 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: add NULL check in automount_fullpathpage is checked for null in __build_path_from_dentry_optional_prefixwhen tcon->origin_fullpath is not set. However, the check is missing whenit is set.Add a check to prevent a potential NULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix fb_set_var to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in fb_set_var() fails to allocate memory forfb_videomode, later it may lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================The reason is that fb_info->var is being modified in fb_set_var(), andthen fb_videomode_to_var() is called. If it fails to add the mode tofb_info->modelist, fb_set_var() returns error, but does not restore theold value of fb_info->var. Restore fb_info->var on failure the same wayit is done earlier in the function.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imx-jpeg: Cleanup after an allocation errorWhen allocation failures are not cleaned up by the driver, furtherallocation errors will be false-positives, which will cause buffers toremain uninitialized and cause NULL pointer dereferences.Ensure proper cleanup of failed allocations to prevent these issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: prevent NULL deref in clip_push()Blamed commit missed that vcc_destroy_socket() callsclip_push() with a NULL skb.If clip_devs is NULL, clip_push() then crashes when readingskb->truesize.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd9335: Fix missing free of regulator suppliesDriver gets and enables all regulator supplies in probe path(wcd9335_parse_dt() and wcd9335_power_on_reset()), but does not cleanupin final error paths and in unbind (missing remove() callback). Thisleads to leaked memory and unbalanced regulator enable count duringprobe errors or unbind.Fix this by converting entire code into devm_regulator_bulk_get_enable()which also greatly simplifies the code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fix NULL pointer in cache_set_flush()1. LINE#1794 - LINE#1887 is some codes about function of bch_cache_set_alloc().2. LINE#2078 - LINE#2142 is some codes about function of register_cache_set().3. register_cache_set() will call bch_cache_set_alloc() in LINE#2098. 1794 struct cache_set *bch_cache_set_alloc(struct cache_sb *sb) 1795 { ... 1860 if (!(c->devices = kcalloc(c->nr_uuids, sizeof(void *), GFP_KERNEL)) || 1861 mempool_init_slab_pool(&c->search, 32, bch_search_cache) || 1862 mempool_init_kmalloc_pool(&c->bio_meta, 2, 1863 sizeof(struct bbio) + sizeof(struct bio_vec) * 1864 bucket_pages(c)) || 1865 mempool_init_kmalloc_pool(&c->fill_iter, 1, iter_size) || 1866 bioset_init(&c->bio_split, 4, offsetof(struct bbio, bio), 1867 BIOSET_NEED_BVECS|BIOSET_NEED_RESCUER) || 1868 !(c->uuids = alloc_bucket_pages(GFP_KERNEL, c)) || 1869 !(c->moving_gc_wq = alloc_workqueue("bcache_gc", 1870 WQ_MEM_RECLAIM, 0)) || 1871 bch_journal_alloc(c) || 1872 bch_btree_cache_alloc(c) || 1873 bch_open_buckets_alloc(c) || 1874 bch_bset_sort_state_init(&c->sort, ilog2(c->btree_pages))) 1875 goto err; ^^^^^^^^ 1876 ... 1883 return c; 1884 err: 1885 bch_cache_set_unregister(c); ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 1886 return NULL; 1887 } ... 2078 static const char *register_cache_set(struct cache *ca) 2079 { ... 2098 c = bch_cache_set_alloc(&ca->sb); 2099 if (!c) 2100 return err; ^^^^^^^^^^ ... 2128 ca->set = c; 2129 ca->set->cache[ca->sb.nr_this_dev] = ca; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... 2138 return NULL; 2139 err: 2140 bch_cache_set_unregister(c); 2141 return err; 2142 }(1) If LINE#1860 - LINE#1874 is true, then do 'goto err'(LINE#1875) and call bch_cache_set_unregister()(LINE#1885).(2) As (1) return NULL(LINE#1886), LINE#2098 - LINE#2100 would return.(3) As (2) has returned, LINE#2128 - LINE#2129 would do *not* give the value to c->cache[], it means that c->cache[] is NULL.LINE#1624 - LINE#1665 is some codes about function of cache_set_flush().As (1), in LINE#1885 callbch_cache_set_unregister()---> bch_cache_set_stop() ---> closure_queue() -.-> cache_set_flush() (as below LINE#1624) 1624 static void cache_set_flush(struct closure *cl) 1625 { ... 1654 for_each_cache(ca, c, i) 1655 if (ca->alloc_thread) ^^ 1656 kthread_stop(ca->alloc_thread); ... 1665 }(4) In LINE#1655 ca is NULL(see (3)) in cache_set_flush() then the kernel crash occurred as below:[ 846.712887] bcache: register_cache() error drbd6: cannot allocate memory[ 846.713242] bcache: register_bcache() error : failed to register device[ 846.713336] bcache: cache_set_free() Cache set 2f84bdc1-498a-4f2f-98a7-01946bf54287 unregistered[ 846.713768] BUG: unable to handle kernel NULL pointer dereference at 00000000000009f8[ 846.714790] PGD 0 P4D 0[ 846.715129] Oops: 0000 [#1] SMP PTI[ 846.715472] CPU: 19 PID: 5057 Comm: kworker/19:16 Kdump: loaded Tainted: G OE --------- - - 4.18.0-147.5.1.el8_1.5es.3.x86_64 #1[ 846.716082] Hardware name: ESPAN GI-25212/X11DPL-i, BIOS 2.1 06/15/2018[ 846.716451] Workqueue: events cache_set_flush [bcache][ 846.716808] RIP: 0010:cache_set_flush+0xc9/0x1b0 [bcache][ 846.717155] Code: 00 4c 89 a5 b0 03 00 00 48 8b 85 68 f6 ff ff a8 08 0f 84 88 00 00 00 31 db 66 83 bd 3c f7 ff ff 00 48 8b 85 48 ff ff ff 74 28 <48> 8b b8 f8 09 00 0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: sanitize request list handlingValidate the request in nvme_tcp_handle_r2t() to ensure it's not part ofany list, otherwise a malicious R2T PDU might inject a loop in requestlist processing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: b53: do not enable EEE on bcm63xxBCM63xx internal switches do not support EEE, but provide multiple RGMIIports where external PHYs may be connected. If one of these PHYs are EEEcapable, we may try to enable EEE for the MACs, which then hangs thesystem on access of the (non-existent) EEE registers.Fix this by checking if the switch actually supports EEE beforeattempting to configure it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38280 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid __bpf_prog_ret0_warn when jit failssyzkaller reported an issue:WARNING: CPU: 3 PID: 217 at kernel/bpf/core.c:2357 __bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Modules linked in:CPU: 3 UID: 0 PID: 217 Comm: kworker/u32:6 Not tainted 6.15.0-rc4-syzkaller-00040-g8bac8898fe39RIP: 0010:__bpf_prog_ret0_warn+0xa/0x20 kernel/bpf/core.c:2357Call Trace: bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] cls_bpf_classify+0x74a/0x1110 net/sched/cls_bpf.c:105 ...When creating bpf program, 'fp->jit_requested' depends on bpf_jit_enable.This issue is triggered because of CONFIG_BPF_JIT_ALWAYS_ON is not setand bpf_jit_enable is set to 1, causing the arch to attempt JIT the prog,but jit failed due to FAULT_INJECTION. As a result, incorrectlytreats the program as valid, when the program runs it calls`__bpf_prog_ret0_warn` and triggers the WARN_ON_ONCE(1).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38285 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix WARN() in get_bpf_raw_tp_regssyzkaller reported an issue:WARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861Modules linked in:CPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861RSP: 0018:ffffc90003636fa8 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4cRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005RBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004R13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900FS: 0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline] bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47 bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline] __bpf_prog_run include/linux/filter.h:718 [inline] bpf_prog_run include/linux/filter.h:725 [inline] __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline] bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405 __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47 __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47 __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline] __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35 __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline] mmap_read_trylock include/linux/mmap_lock.h:204 [inline] stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157 __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483 ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline] bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496 ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline] bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931 bpf_prog_ec3b2eefa702d8d3+0x43/0x47Tracepoint like trace_mmap_lock_acquire_returned may cause nested callas the corner case show above, which will be resolved with more generalmethod in the future. As a result, WARN_ON_ONCE will be triggered. AsAlexei suggested, remove the WARN_ON_ONCE first.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()There is no disagreement that we should check both ptp->is_virtual_clockand ptp->n_vclocks to check if the ptp virtual clock is in use.However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks inptp_vclock_in_use(), we observe a recursive lock in the call tracestarting from n_vclocks_store().============================================WARNING: possible recursive locking detected6.15.0-rc6 #1 Not tainted--------------------------------------------syz.0.1540/13807 is trying to acquire lock:ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415but task is already holding lock:ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at: n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&ptp->n_vclocks_mux); lock(&ptp->n_vclocks_mux); *** DEADLOCK ***....============================================The best way to solve this is to remove the logic that checksptp->n_vclocks in ptp_vclock_in_use().The reason why this is appropriate is that any path that usesptp->n_vclocks must unconditionally check if ptp->n_vclocks is greaterthan 0 before unregistering vclocks, and all functions are alreadywritten this way. And in the function that uses ptp->n_vclocks, wealready get ptp->n_vclocks_mux before unregistering vclocks.Therefore, we need to remove the redundant check for ptp->n_vclocks inptp_vclock_in_use() to prevent recursive locking.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: fix double-free on mc_devThe blamed commit tried to simplify how the deallocations are done but,in the process, introduced a double-free on the mc_dev variable.In case the MC device is a DPRC, a new mc_bus is allocated and themc_dev variable is just a reference to one of its fields. In thiscircumstance, on the error path only the mc_bus should be freed.This commit introduces back the following checkpatch warning which is afalse-positive.WARNING: kfree(NULL) is safe and this check is probably not required+ if (mc_bus)+ kfree(mc_bus);

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pp: Fix potential NULL pointer dereference in atomctrl_initialize_mc_reg_tableThe function atomctrl_initialize_mc_reg_table() andatomctrl_initialize_mc_reg_table_v2_2() does not check the returnvalue of smu_atom_get_data_table(). If smu_atom_get_data_table()fails to retrieve vram_info, it returns NULL which is laterdereferenced.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38326 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:aoe: clean device rq_list in aoedev_downdev()An aoe device's rq_list contains accepted block requests that arewaiting to be transmitted to the aoe target. This queue was added aspart of the conversion to blk_mq. However, the queue was not cleaned outwhen an aoe device is downed which caused blk_mq_freeze_queue() to sleepindefinitely waiting for those requests to complete, causing a hang. Thisfix cleans out the queue before calling blk_mq_freeze_queue().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Use memcpy() for BIOS versionThe strlcat() with FORTIFY support is triggering a panic because itthinks the target buffer will overflow although the correct targetbuffer size is passed in.Anyway, instead of memset() with 0 followed by a strlcat(), just usememcpy() and ensure that the resulting buffer is NULL terminated.BIOSVersion is only used for the lpfc_printf_log() which expects aproperly terminated string.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: fix data-race and null-ptr-deref in jbd2_journal_dirty_metadata()Since handle->h_transaction may be a NULL pointer, so we should change itto call is_handle_aborted(handle) first before dereferencing it.And the following data-race was reported in my fuzzer:==================================================================BUG: KCSAN: data-race in jbd2_journal_dirty_metadata / jbd2_journal_dirty_metadatawrite to 0xffff888011024104 of 4 bytes by task 10881 on cpu 1: jbd2_journal_dirty_metadata+0x2a5/0x770 fs/jbd2/transaction.c:1556 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....read to 0xffff888011024104 of 4 bytes by task 10880 on cpu 0: jbd2_journal_dirty_metadata+0xf2/0x770 fs/jbd2/transaction.c:1512 __ext4_handle_dirty_metadata+0xe7/0x4b0 fs/ext4/ext4_jbd2.c:358 ext4_do_update_inode fs/ext4/inode.c:5220 [inline] ext4_mark_iloc_dirty+0x32c/0xd50 fs/ext4/inode.c:5869 __ext4_mark_inode_dirty+0xe1/0x450 fs/ext4/inode.c:6074 ext4_dirty_inode+0x98/0xc0 fs/ext4/inode.c:6103....value changed: 0x00000000 -> 0x00000001==================================================================This issue is caused by missing data-race annotation for jh->b_modified.Therefore, the missing annotation needs to be added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38344 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi parse and parseext cache leaksACPICA commit 8829e70e1360c81e7a5a901b5d4f48330e021ea5I'm Seunghun Han, and I work for National Security Research Institute ofSouth Korea.I have been doing a research on ACPI and found an ACPI cache leak in ACPIearly abort cases.Boot log of ACPI cache leak is as follows:[ 0.352414] ACPI: Added _OSI(Module Device)[ 0.353182] ACPI: Added _OSI(Processor Device)[ 0.353182] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.353182] ACPI: Added _OSI(Processor Aggregator Device)[ 0.356028] ACPI: Unable to start the ACPI Interpreter[ 0.356799] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.360215] kmem_cache_destroy Acpi-State: Slab cache still has objects[ 0.360648] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #10[ 0.361273] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.361873] Call Trace:[ 0.362243] ? dump_stack+0x5c/0x81[ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.362944] ? acpi_sleep_proc_init+0x27/0x27[ 0.363296] ? acpi_os_delete_cache+0xa/0x10[ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.364000] ? acpi_terminate+0xa/0x14[ 0.364000] ? acpi_init+0x2af/0x34f[ 0.364000] ? __class_create+0x4c/0x80[ 0.364000] ? video_setup+0x7f/0x7f[ 0.364000] ? acpi_sleep_proc_init+0x27/0x27[ 0.364000] ? do_one_initcall+0x4e/0x1a0[ 0.364000] ? kernel_init_freeable+0x189/0x20a[ 0.364000] ? rest_init+0xc0/0xc0[ 0.364000] ? kernel_init+0xa/0x100[ 0.364000] ? ret_from_fork+0x25/0x30I analyzed this memory leak in detail. I found that "Acpi-State" cache and"Acpi-Parse" cache were merged because the size of cache objects was sameslab cache size.I finally found "Acpi-Parse" cache and "Acpi-parse_ext" cache were leakedusing SLAB_NEVER_MERGE flag in kmem_cache_create() function.Real ACPI cache leak point is as follows:[ 0.360101] ACPI: Added _OSI(Module Device)[ 0.360101] ACPI: Added _OSI(Processor Device)[ 0.360101] ACPI: Added _OSI(3.0 _SCP Extensions)[ 0.361043] ACPI: Added _OSI(Processor Aggregator Device)[ 0.364016] ACPI: Unable to start the ACPI Interpreter[ 0.365061] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)[ 0.368174] kmem_cache_destroy Acpi-Parse: Slab cache still has objects[ 0.369332] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.371256] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.372000] Call Trace:[ 0.372000] ? dump_stack+0x5c/0x81[ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? acpi_os_delete_cache+0xa/0x10[ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b[ 0.372000] ? acpi_terminate+0xa/0x14[ 0.372000] ? acpi_init+0x2af/0x34f[ 0.372000] ? __class_create+0x4c/0x80[ 0.372000] ? video_setup+0x7f/0x7f[ 0.372000] ? acpi_sleep_proc_init+0x27/0x27[ 0.372000] ? do_one_initcall+0x4e/0x1a0[ 0.372000] ? kernel_init_freeable+0x189/0x20a[ 0.372000] ? rest_init+0xc0/0xc0[ 0.372000] ? kernel_init+0xa/0x100[ 0.372000] ? ret_from_fork+0x25/0x30[ 0.388039] kmem_cache_destroy Acpi-parse_ext: Slab cache still has objects[ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G W4.12.0-rc4-next-20170608+ #8[ 0.390557] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOSvirtual_box 12/01/2006[ 0.392000] Call Trace:[ 0.392000] ? dump_stack+0x5c/0x81[ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0[ 0.392000] ? acpi_sleep_proc_init+0x27/0x27[ 0.392000] ? acpi_os_delete_cache+0xa/0x10[ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b[ 0.392000] ? acpi_terminate+0xa/0x14[ 0.392000] ? acpi_init+0x2af/0x3---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38359 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/mm: Fix in_atomic() handling in do_secure_storage_access()Kernel user spaces accesses to not exported pages in atomic contextincorrectly try to resolve the page fault.With debug options enabled call traces like this can be seen:BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 419074, name: qemu-system-s39preempt_count: 1, expected: 0RCU nest depth: 0, expected: 0INFO: lockdep is turned off.Preemption disabled at:[<00000383ea47cfa2>] copy_page_from_iter_atomic+0xa2/0x8a0CPU: 12 UID: 0 PID: 419074 Comm: qemu-system-s39Tainted: G W 6.16.0-20250531.rc0.git0.69b3a602feac.63.fc42.s390x+debug #1 PREEMPTTainted: [W]=WARNHardware name: IBM 3931 A01 703 (LPAR)Call Trace: [<00000383e990d282>] dump_stack_lvl+0xa2/0xe8 [<00000383e99bf152>] __might_resched+0x292/0x2d0 [<00000383eaa7c374>] down_read+0x34/0x2d0 [<00000383e99432f8>] do_secure_storage_access+0x108/0x360 [<00000383eaa724b0>] __do_pgm_check+0x130/0x220 [<00000383eaa842e4>] pgm_check_handler+0x114/0x160 [<00000383ea47d028>] copy_page_from_iter_atomic+0x128/0x8a0([<00000383ea47d016>] copy_page_from_iter_atomic+0x116/0x8a0) [<00000383e9c45eae>] generic_perform_write+0x16e/0x310 [<00000383e9eb87f4>] ext4_buffered_write_iter+0x84/0x160 [<00000383e9da0de4>] vfs_write+0x1c4/0x460 [<00000383e9da123c>] ksys_write+0x7c/0x100 [<00000383eaa7284e>] __do_syscall+0x15e/0x280 [<00000383eaa8417e>] system_call+0x6e/0x90INFO: lockdep is turned off.It is not allowed to take the mmap_lock while in atomic context. Thereforehandle such a secure storage access fault as if the accessed page is notmapped: the uaccess function will return -EFAULT, and the caller has todeal with this. Usually this means that the access is retried in processcontext, which allows to resolve the page fault (or in this case export thepage).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38362 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check for get_first_active_display()The function mod_hdcp_hdcp1_enable_encryption() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference inmod_hdcp_hdcp2_enable_encryption().Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38363 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Fix a possible null pointer dereferenceIn tegra_crtc_reset(), new memory is allocated with kzalloc(), butno check is performed. Before calling __drm_atomic_helper_crtc_reset,state should be checked to prevent possible null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38369 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Check availability of workqueue allocated by idxd wq driver before usingRunning IDXD workloads in a container with the /dev directory mounted cantrigger a call trace or even a kernel panic when the parent process of thecontainer is terminated.This issue occurs because, under certain configurations, Docker does notproperly propagate the mount replica back to the original mount point.In this case, when the user driver detaches, the WQ is destroyed but itstill calls destroy_workqueue() attempting to completes all pending work.It's necessary to check wq->wq and skip the drain if it no longer exists.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38371 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Disable interrupts before resetting the GPUCurrently, an interrupt can be triggered during a GPU reset, which canlead to GPU hangs and NULL pointer dereference in an interrupt contextas shown in the following trace: [ 314.035040] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000c0 [ 314.043822] Mem abort info: [ 314.046606] ESR = 0x0000000096000005 [ 314.050347] EC = 0x25: DABT (current EL), IL = 32 bits [ 314.055651] SET = 0, FnV = 0 [ 314.058695] EA = 0, S1PTW = 0 [ 314.061826] FSC = 0x05: level 1 translation fault [ 314.066694] Data abort info: [ 314.069564] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 314.075039] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 314.080080] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 314.085382] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000102728000 [ 314.091814] [00000000000000c0] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 314.100511] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 314.106770] Modules linked in: v3d i2c_brcmstb vc4 snd_soc_hdmi_codec gpu_sched drm_shmem_helper drm_display_helper cec drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 314.129654] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.25+rpt-rpi-v8 #1 Debian 1:6.12.25-1+rpt1 [ 314.139388] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT) [ 314.145211] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 314.152165] pc : v3d_irq+0xec/0x2e0 [v3d] [ 314.156187] lr : v3d_irq+0xe0/0x2e0 [v3d] [ 314.160198] sp : ffffffc080003ea0 [ 314.163502] x29: ffffffc080003ea0 x28: ffffffec1f184980 x27: 021202b000000000 [ 314.170633] x26: ffffffec1f17f630 x25: ffffff8101372000 x24: ffffffec1f17d9f0 [ 314.177764] x23: 000000000000002a x22: 000000000000002a x21: ffffff8103252000 [ 314.184895] x20: 0000000000000001 x19: 00000000deadbeef x18: 0000000000000000 [ 314.192026] x17: ffffff94e51d2000 x16: ffffffec1dac3cb0 x15: c306000000000000 [ 314.199156] x14: 0000000000000000 x13: b2fc982e03cc5168 x12: 0000000000000001 [ 314.206286] x11: ffffff8103f8bcc0 x10: ffffffec1f196868 x9 : ffffffec1dac3874 [ 314.213416] x8 : 0000000000000000 x7 : 0000000000042a3a x6 : ffffff810017a180 [ 314.220547] x5 : ffffffec1ebad400 x4 : ffffffec1ebad320 x3 : 00000000000bebeb [ 314.227677] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 314.234807] Call trace: [ 314.237243] v3d_irq+0xec/0x2e0 [v3d] [ 314.240906] __handle_irq_event_percpu+0x58/0x218 [ 314.245609] handle_irq_event+0x54/0xb8 [ 314.249439] handle_fasteoi_irq+0xac/0x240 [ 314.253527] handle_irq_desc+0x48/0x68 [ 314.257269] generic_handle_domain_irq+0x24/0x38 [ 314.261879] gic_handle_irq+0x48/0xd8 [ 314.265533] call_on_irq_stack+0x24/0x58 [ 314.269448] do_interrupt_handler+0x88/0x98 [ 314.273624] el1_interrupt+0x34/0x68 [ 314.277193] el1h_64_irq_handler+0x18/0x28 [ 314.281281] el1h_64_irq+0x64/0x68 [ 314.284673] default_idle_call+0x3c/0x168 [ 314.288675] do_idle+0x1fc/0x230 [ 314.291895] cpu_startup_entry+0x3c/0x50 [ 314.295810] rest_init+0xe4/0xf0 [ 314.299030] start_kernel+0x5e8/0x790 [ 314.302684] __primary_switched+0x80/0x90 [ 314.306691] Code: 940029eb 360ffc13 f9442ea0 52800001 (f9406017) [ 314.312775] ---[ end trace 0000000000000000 ]--- [ 314.317384] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 314.324249] SMP: stopping secondary CPUs [ 314.328167] Kernel Offset: 0x2b9da00000 from 0xffffffc080000000 [ 314.334076] PHYS_OFFSET: 0x0 [ 314.336946] CPU features: 0x08,00002013,c0200000,0200421b [ 314.342337] Memory Limit: none [ 314.345382] ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---Before resetting the G---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38386 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Refuse to evaluate a method if arguments are missingAs reported in [1], a platform firmware update that increased the numberof method parameters and forgot to update a least one of its callers,caused ACPICA to crash due to use-after-free.Since this a result of a clear AML issue that arguably cannot be fixedup by the interpreter (it cannot produce missing data out of thin air),address it by making ACPICA refuse to evaluate a method if the callerattempts to pass fewer arguments than expected to it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38389 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix timeline left held on VMA alloc errorThe following error has been reported sporadically by CI when a testunbinds the i915 driver on a ring submission platform:<4> [239.330153] ------------[ cut here ]------------<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]...<4> [239.330942] Call Trace:<4> [239.330944] <4> [239.330949] i915_driver_late_release+0x2b/0xa0 [i915]<4> [239.331202] i915_driver_release+0x86/0xa0 [i915]<4> [239.331482] devm_drm_dev_init_release+0x61/0x90<4> [239.331494] devm_action_release+0x15/0x30<4> [239.331504] release_nodes+0x3d/0x120<4> [239.331517] devres_release_all+0x96/0xd0<4> [239.331533] device_unbind_cleanup+0x12/0x80<4> [239.331543] device_release_driver_internal+0x23a/0x280<4> [239.331550] ? bus_find_device+0xa5/0xe0<4> [239.331563] device_driver_detach+0x14/0x20...<4> [357.719679] ---[ end trace 0000000000000000 ]---If the test also unloads the i915 module then that's followed with:<3> [357.787478] =============================================================================<3> [357.788006] BUG i915_vma (Tainted: G U W N ): Objects remaining on __kmem_cache_shutdown()<3> [357.788031] -----------------------------------------------------------------------------<3> [357.788204] Object 0xffff888109e7f480 @offset=29824<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244<4> [357.788994] i915_vma_instance+0xee/0xc10 [i915]<4> [357.789290] init_status_page+0x7b/0x420 [i915]<4> [357.789532] intel_engines_init+0x1d8/0x980 [i915]<4> [357.789772] intel_gt_init+0x175/0x450 [i915]<4> [357.790014] i915_gem_init+0x113/0x340 [i915]<4> [357.790281] i915_driver_probe+0x847/0xed0 [i915]<4> [357.790504] i915_pci_probe+0xe6/0x220 [i915]...Closer analysis of CI results history has revealed a dependency of theerror on a few IGT tests, namely:- igt@api_intel_allocator@fork-simple-stress-signal,- igt@api_intel_allocator@two-level-inception-interruptible,- igt@gem_linear_blits@interruptible,- igt@prime_mmap_coherency@ioctl-errors,which invisibly trigger the issue, then exhibited with first driver unbindattempt.All of the above tests perform actions which are actively interrupted withsignals. Further debugging has allowed to narrow that scope down toDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ringsubmission, in particular.If successful then that function, or its execlists or GuC submissionequivalent, is supposed to be called only once per GEM context engine,followed by raise of a flag that prevents the function from being calledagain. The function is expected to unwind its internal errors itself, soit may be safely called once more after it returns an error.In case of ring submission, the function first gets a reference to theengine's legacy timeline and then allocates a VMA. If the VMA allocationfails, e.g. when i915_vma_instance() called from inside is interruptedwith a signal, then ring_context_alloc() fails, leaving the timeline heldreferenced. On next I915_GEM_EXECBUFFER2 IOCTL, another reference to thetimeline is got, and only that last one is put on successful completion.As a consequence, the legacy timeline, with its underlying engine statuspage's VMA object, is still held and not released on driver unbind.Get the legacy timeline only after successful allocation of the contextengine's VMA.v2: Add a note on other submission methods (Krzysztof Karas): Both execlists and GuC submission use lrc_alloc() which seems free from a similar issue.(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38392 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: convert control queue mutex to a spinlockWith VIRTCHNL2_CAP_MACFILTER enabled, the following warning is generatedon module load:[ 324.701677] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:578[ 324.701684] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1582, name: NetworkManager[ 324.701689] preempt_count: 201, expected: 0[ 324.701693] RCU nest depth: 0, expected: 0[ 324.701697] 2 locks held by NetworkManager/1582:[ 324.701702] #0: ffffffff9f7be770 (rtnl_mutex){....}-{3:3}, at: rtnl_newlink+0x791/0x21e0[ 324.701730] #1: ff1100216c380368 (_xmit_ETHER){....}-{2:2}, at: __dev_open+0x3f0/0x870[ 324.701749] Preemption disabled at:[ 324.701752] [] __dev_open+0x3dd/0x870[ 324.701765] CPU: 30 UID: 0 PID: 1582 Comm: NetworkManager Not tainted 6.15.0-rc5+ #2 PREEMPT(voluntary)[ 324.701771] Hardware name: Intel Corporation M50FCP2SBSTD/M50FCP2SBSTD, BIOS SE5C741.86B.01.01.0001.2211140926 11/14/2022[ 324.701774] Call Trace:[ 324.701777] [ 324.701779] dump_stack_lvl+0x5d/0x80[ 324.701788] ? __dev_open+0x3dd/0x870[ 324.701793] __might_resched.cold+0x1ef/0x23d<..>[ 324.701818] __mutex_lock+0x113/0x1b80<..>[ 324.701917] idpf_ctlq_clean_sq+0xad/0x4b0 [idpf][ 324.701935] ? kasan_save_track+0x14/0x30[ 324.701941] idpf_mb_clean+0x143/0x380 [idpf]<..>[ 324.701991] idpf_send_mb_msg+0x111/0x720 [idpf][ 324.702009] idpf_vc_xn_exec+0x4cc/0x990 [idpf][ 324.702021] ? rcu_is_watching+0x12/0xc0[ 324.702035] idpf_add_del_mac_filters+0x3ed/0xb50 [idpf]<..>[ 324.702122] __hw_addr_sync_dev+0x1cf/0x300[ 324.702126] ? find_held_lock+0x32/0x90[ 324.702134] idpf_set_rx_mode+0x317/0x390 [idpf][ 324.702152] __dev_open+0x3f8/0x870[ 324.702159] ? __pfx___dev_open+0x10/0x10[ 324.702174] __dev_change_flags+0x443/0x650<..>[ 324.702208] netif_change_flags+0x80/0x160[ 324.702218] do_setlink.isra.0+0x16a0/0x3960<..>[ 324.702349] rtnl_newlink+0x12fd/0x21e0The sequence is as follows: rtnl_newlink()-> __dev_change_flags()-> __dev_open()-> dev_set_rx_mode() - > # disables BH and grabs "dev->addr_list_lock" idpf_set_rx_mode() -> # proceed only if VIRTCHNL2_CAP_MACFILTER is ON __dev_uc_sync() -> idpf_add_mac_filter -> idpf_add_del_mac_filters -> idpf_send_mb_msg() -> idpf_mb_clean() -> idpf_ctlq_clean_sq() # mutex_lock(cq_lock)Fix by converting cq_lock to a spinlock. All operations under the newlock are safe except freeing the DMA memory, which may use vunmap(). Fixby requesting a contiguous physical memory for the DMA mapping.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38399 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Fix NULL pointer dereference in core_scsi3_decode_spec_i_port()The function core_scsi3_decode_spec_i_port(), in its error code path,unconditionally calls core_scsi3_lunacl_undepend_item() passing thedest_se_deve pointer, which may be NULL.This can lead to a NULL pointer dereference if dest_se_deve remainsunset.SPC-3 PR SPEC_I_PT: Unable to locate dest_tpgUnable to handle kernel paging request at virtual address dfff800000000012Call trace: core_scsi3_lunacl_undepend_item+0x2c/0xf0 [target_core_mod] (P) core_scsi3_decode_spec_i_port+0x120c/0x1c30 [target_core_mod] core_scsi3_emulate_pro_register+0x6b8/0xcd8 [target_core_mod] target_scsi3_emulate_pr_out+0x56c/0x840 [target_core_mod]Fix this by adding a NULL check before callingcore_scsi3_lunacl_undepend_item()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38402 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: return 0 size for RSS key if not supportedReturning -EOPNOTSUPP from function returning u32 is leading tocast and invalid size value as a result.-EOPNOTSUPP as a size probably will lead to allocation fail.Command: ethtool -x eth0It is visible on all devices that don't have RSS caps set.[ 136.615917] Call Trace:[ 136.615921] [ 136.615927] ? __warn+0x89/0x130[ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.615953] ? report_bug+0x164/0x190[ 136.615968] ? handle_bug+0x58/0x90[ 136.615979] ? exc_invalid_op+0x17/0x70[ 136.615987] ? asm_exc_invalid_op+0x1a/0x20[ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330[ 136.616028] __alloc_pages_noprof+0xe/0x20[ 136.616038] ___kmalloc_large_node+0x80/0x110[ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0[ 136.616081] __kmalloc_noprof+0x32c/0x4c0[ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170[ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170[ 136.616114] ethnl_default_doit+0x107/0x3d0[ 136.616131] genl_family_rcv_msg_doit+0x100/0x160[ 136.616147] genl_rcv_msg+0x1b8/0x2c0[ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10[ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10[ 136.616176] netlink_rcv_skb+0x58/0x110[ 136.616186] genl_rcv+0x28/0x40[ 136.616195] netlink_unicast+0x19b/0x290[ 136.616206] netlink_sendmsg+0x222/0x490[ 136.616215] __sys_sendto+0x1fd/0x210[ 136.616233] __x64_sys_sendto+0x24/0x30[ 136.616242] do_syscall_64+0x82/0x160[ 136.616252] ? __sys_recvmsg+0x83/0xe0[ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210[ 136.616275] ? do_syscall_64+0x8e/0x160[ 136.616282] ? __count_memcg_events+0xa1/0x130[ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30[ 136.616306] ? handle_mm_fault+0xae/0x2d0[ 136.616319] ? do_user_addr_fault+0x379/0x670[ 136.616328] ? clear_bhb_loop+0x45/0xa0[ 136.616340] ? clear_bhb_loop+0x45/0xa0[ 136.616349] ? clear_bhb_loop+0x45/0xa0[ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 136.616369] RIP: 0033:0x7fd30ba7b047[ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44[ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c[ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047[ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003[ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c[ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340[ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38406 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: remove WARN on bad firmware inputIf the firmware gives bad input, that's nothing to do withthe driver's stack at this point etc., so the WARN_ON()doesn't add any value. Additionally, this is one of thetop syzbot reports now. Just print a message, and as anadded bonus, print the sizes too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38410 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix a fence leak in submit error pathIn error paths, we could unref the submit without callingdrm_sched_entity_push_job(), so msm_job_free() will never getcalled. Since drm_sched_job_cleanup() will NULL out thes_fence, we can use that to detect this case.Patchwork: https://patchwork.freedesktop.org/patch/653584/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38412 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: dell-wmi-sysman: Fix WMI data block retrieval in sysfs callbacksAfter retrieving WMI data blocks in sysfs callbacks, check for thevalidity of them before dereferencing their content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38418 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Release rproc->clean_table after rproc_attach() failsWhen rproc->state = RPROC_DETACHED is attached to remote processorthrough rproc_attach(), if rproc_handle_resources() returns failure,then the clean table should be released, otherwise the followingmemory leak will occur.unreferenced object 0xffff000086a99800 (size 1024):comm "kworker/u12:3", pid 59, jiffies 4294893670 (age 121.140s)hex dump (first 32 bytes):00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............backtrace: [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230 [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260 [<0000000037818dae>] kmemdup+0x34/0x60 [<00000000610f7f57>] rproc_boot+0x35c/0x56c [<0000000065f8871a>] rproc_add+0x124/0x17c [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4 [<000000003bcaa37d>] platform_probe+0x68/0xd8 [<00000000771577f9>] really_probe+0x110/0x27c [<00000000531fea59>] __driver_probe_device+0x78/0x12c [<0000000080036a04>] driver_probe_device+0x3c/0x118 [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8 [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4 [<000000001a53b53e>] __device_attach+0xfc/0x18c [<00000000d1a2a32c>] device_initial_probe+0x14/0x20 [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4 unreferenced object 0xffff0000864c9690 (size 16):

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38419 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()When rproc->state = RPROC_DETACHED and rproc_attach() is usedto attach to the remote processor, if rproc_handle_resources()returns a failure, the resources allocated by imx_rproc_prepare()should be released, otherwise the following memory leak will occur.Since almost the same thing is done in imx_rproc_prepare() andrproc_resource_cleanup(), Function rproc_resource_cleanup() is ableto deal with empty lists so it is better to fix the "goto" statementsin rproc_attach(). replace the "unprepare_device" goto statement with"clean_up_resources" and get rid of the "unprepare_device" label.unreferenced object 0xffff0000861c5d00 (size 128):comm "kworker/u12:3", pid 59, jiffies 4294893509 (age 149.220s)hex dump (first 32 bytes):00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............backtrace: [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0 [<00000000521c0345>] kmalloc_trace+0x40/0x158 [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8 [<000000002815755e>] imx_rproc_prepare+0xe0/0x180 [<0000000003f61b4e>] rproc_boot+0x2ec/0x528 [<00000000e7e994ac>] rproc_add+0x124/0x17c [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4 [<00000000efc298a1>] platform_probe+0x68/0xd8 [<00000000110be6fe>] really_probe+0x110/0x27c [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118 [<00000000a7874938>] __device_attach_driver+0xb8/0xf8 [<0000000065319e69>] bus_for_each_drv+0x84/0xe4 [<00000000db3eb243>] __device_attach+0xfc/0x18c [<0000000072e4e1a4>] device_initial_probe+0x14/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38420 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: do not ping device which has failed to load firmwareSyzkaller reports [1, 2] crashes caused by an attempts to pingthe device which has failed to load firmware. Since such a devicedoesn't pass 'ieee80211_register_hw()', an internal workqueuemanaged by 'ieee80211_queue_work()' is not yet created and anattempt to queue work on it causes null-ptr-deref.[1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff[2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38424 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf: Fix sample vs do_exit()Baisheng Gao reported an ARM64 crash, which Mark decoded as being asynchronous external abort -- most likely due to trying to accessMMIO in bad ways.The crash further shows perf trying to do a user stack sample while inexit_mmap()'s tlb_finish_mmu() -- i.e. while tearing down the addressspace it is trying to access.It turns out that we stop perf after we tear down the userspace mm; areceipie for disaster, since perf likes to access userspace forvarious reasons.Flip this order by moving up where we stop perf in do_exit().Additionally, harden PERF_SAMPLE_CALLCHAIN and PERF_SAMPLE_STACK_USERto abort when the current task does not have an mm (exit_mm() makessure to set current->mm = NULL; before commencing with the actualteardown). Such that CPU wide events don't trip on this same problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38426 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Add basic validation for RAS headerIf RAS header read from EEPROM is corrupted, it could result in tryingto allocate huge memory for reading the records. Add some validation toheader fields.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38430 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: nfsd4_spo_must_allow() must check this is a v4 compound requestIf the request being processed is not a v4 compound request, thenexamining the cstate can have undefined results.This patch adds a check that the rpc procedure being executed(rq_procinfo) is the NFSPROC4_COMPOUND procedure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38438 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Intel: hda: Use devm_kstrdup() to avoid memleak.sof_pdata->tplg_filename can have address allocated by kstrdup()and can be overwritten. Memory leak was detected with kmemleak:unreferenced object 0xffff88812391ff60 (size 16): comm "kworker/4:1", pid 161, jiffies 4294802931 hex dump (first 16 bytes): 73 6f 66 2d 68 64 61 2d 67 65 6e 65 72 69 63 00 sof-hda-generic. backtrace (crc 4bf1675c): __kmalloc_node_track_caller_noprof+0x49c/0x6b0 kstrdup+0x46/0xc0 hda_machine_select.cold+0x1de/0x12cf [snd_sof_intel_hda_generic] sof_init_environment+0x16f/0xb50 [snd_sof] sof_probe_continue+0x45/0x7c0 [snd_sof] sof_probe_work+0x1e/0x40 [snd_sof] process_one_work+0x894/0x14b0 worker_thread+0x5e5/0xfb0 kthread+0x39d/0x760 ret_from_fork+0x31/0x70 ret_from_fork_asm+0x1a/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38444 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:raid10: cleanup memleak at raid10_make_requestIf raid10_read_request or raid10_write_request registers a newrequest and the REQ_NOWAIT flag is set, the code does notfree the malloc from the mempool.unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc c1a049a2): __kmalloc+0x2bb/0x450 mempool_alloc+0x11b/0x320 raid10_make_request+0x19e/0x650 [raid10] md_handle_request+0x3b3/0x9e0 __submit_bio+0x394/0x560 __submit_bio_noacct+0x145/0x530 submit_bio_noacct_nocheck+0x682/0x830 __blkdev_direct_IO_async+0x4dc/0x6b0 blkdev_read_iter+0x1e5/0x3b0 __io_read+0x230/0x1110 io_read+0x13/0x30 io_issue_sqe+0x134/0x1180 io_submit_sqes+0x48c/0xe90 __do_sys_io_uring_enter+0x574/0x8b0 do_syscall_64+0x5c/0xe0 entry_SYSCALL_64_after_hwframe+0x76/0x7eV4: changing backing tree to see if CKI tests will pass.The patch code has not changed between any versions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38445 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid1: Fix stack memory use after return in raid1_reshapeIn the raid1_reshape function, newpool isallocated on the stack and assigned to conf->r1bio_pool.This results in conf->r1bio_pool.wait.head pointingto a stack address.Accessing this address later can lead to a kernel panic.Example access path:raid1_reshape(){ // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init(&newpool, ...); conf->r1bio_pool = newpool;}raid1_read_request() or raid1_write_request(){ alloc_r1bio() { mempool_alloc() { // if pool->alloc fails remove_element() { --pool->curr_nr; } } }}mempool_free(){ if (pool->curr_nr < pool->min_nr) { // pool->wait.head is a stack address // wake_up() will try to access this invalid address // which leads to a kernel panic return; wake_up(&pool->wait); }}Fix:reinit conf->r1bio_pool.wait after assigning newpool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38457 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Abort __tc_modify_qdisc if parent class does not existLion's patch [1] revealed an ancient bug in the qdisc API.Whenever a user creates/modifies a qdisc specifying as a parent anotherqdisc, the qdisc API will, during grafting, detect that the user isnot trying to attach to a class and reject. However grafting isperformed after qdisc_create (and thus the qdiscs' init callback) isexecuted. In qdiscs that eventually call qdisc_tree_reduce_backlogduring init or change (such as fq, hhf, choke, etc), an issuearises. For example, executing the following commands:sudo tc qdisc add dev lo root handle a: htb default 2sudo tc qdisc add dev lo parent a: handle beef fqQdiscs such as fq, hhf, choke, etc unconditionally invokeqdisc_tree_reduce_backlog() in their control path init() or change() whichthen causes a failure to find the child class; however, that does not stopthe unconditional invocation of the assumed child qdisc's qlen_notify witha null class. All these qdiscs make the assumption that class is non-null.The solution is ensure that qdisc_leaf() which looks up the parentclass, and is invoked prior to qdisc_create(), should return failure onnot finding the class.In this patch, we leverage qdisc_leaf to return ERR_PTRs whenever theparentid doesn't correspond to a class, so that we can detect itearlier on and abort before qdisc_create is called.[1] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38458 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: clip: Fix NULL pointer dereference in vcc_sendmsg()atmarpd_dev_ops does not implement the send method, which may cause crashas bellow.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: Oops: 0010 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246RAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000RDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000RBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287R10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00R13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88FS: 00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:727 ____sys_sendmsg+0x52d/0x830 net/socket.c:2566 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620 __sys_sendmmsg+0x227/0x430 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38465 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: Fix wraparounds of sk->sk_rmem_alloc.Netlink has this pattern in some places if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) atomic_add(skb->truesize, &sk->sk_rmem_alloc);, which has the same problem fixed by commit 5a465a0da13e ("udp:Fix multiple wraparounds of sk->sk_rmem_alloc.").For example, if we set INT_MAX to SO_RCVBUFFORCE, the conditionis always false as the two operands are of int.Then, a single socket can eat as many skb as possible until OOMhappens, and we can see multiple wraparounds of sk->sk_rmem_alloc.Let's fix it by using atomic_add_return() and comparing the twovariables as unsigned int.Before: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port -1668710080 0 rtnl:nl_wraparound/293 *After: [root@fedora ~]# ss -f netlink Recv-Q Send-Q Local Address:Port Peer Address:Port 2147483072 0 rtnl:nl_wraparound/290 * ^ `--- INT_MAX - 576

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38474 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: net: sierra: check for no status endpointThe driver checks for having three endpoints andhaving bulk in and out endpoints, but not thatthe third endpoint is interrupt input.Rectify the omission.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38487 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:soc: aspeed: lpc-snoop: Don't disable channels that aren't enabledMitigate e.g. the following: # echo 1e789080.lpc-snoop > /sys/bus/platform/drivers/aspeed-lpc-snoop/unbind ... [ 120.363594] Unable to handle kernel NULL pointer dereference at virtual address 00000004 when write [ 120.373866] [00000004] *pgd=00000000 [ 120.377910] Internal error: Oops: 805 [#1] SMP ARM [ 120.383306] CPU: 1 UID: 0 PID: 315 Comm: sh Not tainted 6.15.0-rc1-00009-g926217bc7d7d-dirty #20 NONE ... [ 120.679543] Call trace: [ 120.679559] misc_deregister from aspeed_lpc_snoop_remove+0x84/0xac [ 120.692462] aspeed_lpc_snoop_remove from platform_remove+0x28/0x38 [ 120.700996] platform_remove from device_release_driver_internal+0x188/0x200 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38503 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix assertion when building free space treeWhen building the free space tree with the block group tree featureenabled, we can hit an assertion failure like this: BTRFS info (device loop0 state M): rebuilding free space tree assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1102! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP Modules linked in: CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 sp : ffff8000a4ce7600 x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8 x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001 x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160 x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0 x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00 x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001 x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0 x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e Call trace: populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P) btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337 btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074 btrfs_remount_rw fs/btrfs/super.c:1319 [inline] btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543 reconfigure_super+0x1d4/0x6f0 fs/super.c:1083 do_remount fs/namespace.c:3365 [inline] path_mount+0xb34/0xde0 fs/namespace.c:4200 do_mount fs/namespace.c:4221 [inline] __do_sys_mount fs/namespace.c:4432 [inline] __se_sys_mount fs/namespace.c:4409 [inline] __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767 el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786 el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600 Code: f0047182 91178042 528089c3 9771d47b (d4210000) ---[ end trace 0000000000000000 ]---This happens because we are processing an empty block group, which hasno extents allocated from it, there are no items for this block group,including the block group item since block group items are stored in adedicated tree when using the block group tree feature. It also meansthis is the block group with the highest start offset, so there are nohigher keys in the extent root, hence btrfs_search_slot_for_read()returns 1 (no higher key found).Fix this by asserting 'ret' is 0 only if the block group tree featureis not enabled, in which case we should find a block group item forthe block group since it's stored in the extent root and block groupitem keys are greater than extent item keys (the value forBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY andBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).In case 'ret' is 1, we just need to add a record to the free spacetree which spans the whole block group, and we can achieve this bymaking 'ret == 0' as the while loop's condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38509 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: reject VHT opmode for unsupported channel widthsVHT operating mode notifications are not defined for channel widthsbelow 20 MHz. In particular, 5 MHz and 10 MHz are not valid under theVHT specification and must be rejected.Without this check, malformed notifications using these widths mayreach ieee80211_chan_width_to_rx_bw(), leading to a WARN_ON due toinvalid input. This issue was reported by syzbot.Reject these unsupported widths early in sta_link_apply_parameters()when opmode_notif is used. The accepted set includes 20, 40, 80, 160,and 80+80 MHz, which are valid for VHT. While 320 MHz is not definedfor VHT, it is allowed to avoid rejecting HE or EHT clients that maystill send a VHT opmode notification.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38514 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix oops due to non-existence of prealloc backlog structIf an AF_RXRPC service socket is opened and bound, but calls arepreallocated, then rxrpc_alloc_incoming_call() will oops because therxrpc_backlog struct doesn't get allocated until the first preallocation ismade.Fix this by returning NULL from rxrpc_alloc_incoming_call() if there is nobacklog struct. This will cause the incoming call to be aborted.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38516 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: qcom: msm: mark certain pins as invalid for interruptsOn some platforms, the UFS-reset pin has no interrupt logic in TLMM butis nevertheless registered as a GPIO in the kernel. This enables theuser-space to trigger a BUG() in the pinctrl-msm driver by running, forexample: `gpiomon -c 0 113` on RB2.The exact culprit is requesting pins whose intr_detection_width settingis not 1 or 2 for interrupts. This hits a BUG() inmsm_gpio_irq_set_type(). Potentially crashing the kernel due to aninvalid request from user-space is not optimal, so let's go through thepins and mark those that would fail the check as invalid for the irq chipas we should not even register them as available irqs.This function can be extended if we determine that there are morecorner-cases like this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38524 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix recv-recv race of completed callIf a call receives an event (such as incoming data), the call gets placedon the socket's queue and a thread in recvmsg can be awakened to go andprocess it. Once the thread has picked up the call off of the queue,further events will cause it to be requeued, and once the socket lock isdropped (recvmsg uses call->user_mutex to allow the socket to be used inparallel), a second thread can come in and its recvmsg can pop the call offthe socket queue again.In such a case, the first thread will be receiving stuff from the call andthe second thread will be blocked on call->user_mutex. The first threadcan, at this point, process both the event that it picked call for and theevent that the second thread picked the call for and may see the callterminate - in which case the call will be "released", decoupling the callfrom the user call ID assigned to it (RXRPC_USER_CALL_ID in the controlmessage).The first thread will return okay, but then the second thread will wake upholding the user_mutex and, if it sees that the call has been released bythe first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474!Fix this by just dequeuing the call and ignoring it if it is seen to bealready released. We can't tell userspace about it anyway as the user callID has become stale.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38535 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Fix unbalanced regulator disable in UTMI PHY modeWhen transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the codeassumed that the regulator should be disabled. However, if the regulatoris marked as always-on, regulator_is_enabled() continues to return true,leading to an incorrect attempt to disable a regulator which is notenabled.This can result in warnings such as:[ 250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004_regulator_disable+0xe4/0x1a0[ 250.155652] unbalanced disables for VIN_SYS_5V0To fix this, we move the regulator control logic intotegra186_xusb_padctl_id_override() function since it's directly relatedto the ID override state. The regulator is now only disabled when the roletransitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_IDregister. This ensures that regulator enable/disable operations areproperly balanced and only occur when actually transitioning to/from hostmode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38540 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: quirks: Add quirk for 2 Chicony Electronics HP 5MP CamerasThe Chicony Electronics HP 5MP Cameras (USB ID 04F2:B824 & 04F2:B82C)report a HID sensor interface that is not actually implemented.Attempting to access this non-functional sensor via iio_info causessystem hangs as runtime PM tries to wake up an unresponsive sensor.Add these 2 devices to the HID ignore list since the sensor interface isnon-functional by design and should not be exposed to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38548 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (corsair-cpro) Validate the size of the received input bufferAdd buffer_recv_size to store the size of the received bytes.Validate buffer_recv_size in send_usb_cmd().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38550 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: Delay put pmc->idev in mld_del_delrec()pmc->idev is still used in ip6_mc_clear_src(), so as mld_clear_delrec()does, the reference should be put after ip6_mc_clear_src() return.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38581 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: ccp - Fix crash when rebind ccp device for ccp.koWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebindingthe ccp device causes the following crash:$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind[ 204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098[ 204.978026] #PF: supervisor write access in kernel mode[ 204.979126] #PF: error_code(0x0002) - not-present page[ 204.980226] PGD 0 P4D 0[ 204.981317] Oops: Oops: 0002 [#1] SMP NOPTI...[ 204.997852] Call Trace:[ 204.999074] [ 205.000297] start_creating+0x9f/0x1c0[ 205.001533] debugfs_create_dir+0x1f/0x170[ 205.002769] ? srso_return_thunk+0x5/0x5f[ 205.004000] ccp5_debugfs_setup+0x87/0x170 [ccp][ 205.005241] ccp5_init+0x8b2/0x960 [ccp][ 205.006469] ccp_dev_init+0xd4/0x150 [ccp][ 205.007709] sp_init+0x5f/0x80 [ccp][ 205.008942] sp_pci_probe+0x283/0x2e0 [ccp][ 205.010165] ? srso_return_thunk+0x5/0x5f[ 205.011376] local_pci_probe+0x4f/0xb0[ 205.012584] pci_device_probe+0xdb/0x230[ 205.013810] really_probe+0xed/0x380[ 205.015024] __driver_probe_device+0x7e/0x160[ 205.016240] device_driver_attach+0x2f/0x60[ 205.017457] bind_store+0x7c/0xb0[ 205.018663] drv_attr_store+0x28/0x40[ 205.019868] sysfs_kf_write+0x5f/0x70[ 205.021065] kernfs_fop_write_iter+0x145/0x1d0[ 205.022267] vfs_write+0x308/0x440[ 205.023453] ksys_write+0x6d/0xe0[ 205.024616] __x64_sys_write+0x1e/0x30[ 205.025778] x64_sys_call+0x16ba/0x2150[ 205.026942] do_syscall_64+0x56/0x1e0[ 205.028108] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 205.029276] RIP: 0033:0x7fbc36f10104[ 205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5This patch sets ccp_debugfs_dir to NULL after destroying it inccp5_debugfs_destroy, allowing the directory dentry to berecreated when rebinding the ccp device.Tested on AMD Ryzen 7 1700X.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38583 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: xilinx: vcu: unregister pll_post only if registered correctlyIf registration of pll_post is failed, it will be set to NULL or ERR,unregistering same will fail with following call trace:Unable to handle kernel NULL pointer dereference at virtual address 008pc : clk_hw_unregister+0xc/0x20lr : clk_hw_unregister_fixed_factor+0x18/0x30sp : ffff800011923850...Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38590 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Remove skb secpath if xfrm state is not foundHardware returns a unique identifier for a decrypted packet's xfrmstate, this state is looked up in an xarray. However, the state mighthave been freed by the time of this lookup.Currently, if the state is not found, only a counter is incremented.The secpath (sp) extension on the skb is not removed, resulting insp->len becoming 0.Subsequently, functions like __xfrm_policy_check() attempt to accessfields such as xfrm_input_state(skb)->xso.type (which dereferencessp->xvec[sp->len - 1]) without first validating sp->len. This leads toa crash when dereferencing an invalid state pointer.This patch prevents the crash by explicitly removing the secpathextension from the skb if the xfrm state is not found after hardwaredecryption. This ensures downstream functions do not operate on azero-length secpath. BUG: unable to handle page fault for address: ffffffff000002c8 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 282e067 P4D 282e067 PUD 0 Oops: Oops: 0000 [#1] SMP CPU: 12 UID: 0 PID: 0 Comm: swapper/12 Not tainted 6.15.0-rc7_for_upstream_min_debug_2025_05_27_22_44 #1 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:__xfrm_policy_check+0x61a/0xa30 Code: b6 77 7f 83 e6 02 74 14 4d 8b af d8 00 00 00 41 0f b6 45 05 c1 e0 03 48 98 49 01 c5 41 8b 45 00 83 e8 01 48 98 49 8b 44 c5 10 <0f> b6 80 c8 02 00 00 83 e0 0c 3c 04 0f 84 0c 02 00 00 31 ff 80 fa RSP: 0018:ffff88885fb04918 EFLAGS: 00010297 RAX: ffffffff00000000 RBX: 0000000000000002 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000002 RDI: 0000000000000000 RBP: ffffffff8311af80 R08: 0000000000000020 R09: 00000000c2eda353 R10: ffff88812be2bbc8 R11: 000000001faab533 R12: ffff88885fb049c8 R13: ffff88812be2bbc8 R14: 0000000000000000 R15: ffff88811896ae00 FS: 0000000000000000(0000) GS:ffff8888dca82000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffff000002c8 CR3: 0000000243050002 CR4: 0000000000372eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? try_to_wake_up+0x108/0x4c0 ? udp4_lib_lookup2+0xbe/0x150 ? udp_lib_lport_inuse+0x100/0x100 ? __udp4_lib_lookup+0x2b0/0x410 __xfrm_policy_check2.constprop.0+0x11e/0x130 udp_queue_rcv_one_skb+0x1d/0x530 udp_unicast_rcv_skb+0x76/0x90 __udp4_lib_rcv+0xa64/0xe90 ip_protocol_deliver_rcu+0x20/0x130 ip_local_deliver_finish+0x75/0xa0 ip_local_deliver+0xc1/0xd0 ? ip_protocol_deliver_rcu+0x130/0x130 ip_sublist_rcv+0x1f9/0x240 ? ip_rcv_finish_core+0x430/0x430 ip_list_rcv+0xfc/0x130 __netif_receive_skb_list_core+0x181/0x1e0 netif_receive_skb_list_internal+0x200/0x360 ? mlx5e_build_rx_skb+0x1bc/0xda0 [mlx5_core] gro_receive_skb+0xfd/0x210 mlx5e_handle_rx_cqe_mpwrq+0x141/0x280 [mlx5_core] mlx5e_poll_rx_cq+0xcc/0x8e0 [mlx5_core] ? mlx5e_handle_rx_dim+0x91/0xd0 [mlx5_core] mlx5e_napi_poll+0x114/0xab0 [mlx5_core] __napi_poll+0x25/0x170 net_rx_action+0x32d/0x3a0 ? mlx5_eq_comp_int+0x8d/0x280 [mlx5_core] ? notifier_call_chain+0x33/0xa0 handle_softirqs+0xda/0x250 irq_exit_rcu+0x6d/0xc0 common_interrupt+0x81/0xa0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38601 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: clear initialized flag for deinit-ed srng listsIn a number of cases we see kernel panics on resume dueto ath11k kernel page fault, which happens under thefollowing circumstances:1) First ath11k_hal_dump_srng_stats() call Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 22511ms before ath11k_pci 0000:01:00.0: group_id 1 14440788ms before [..] ath11k_pci 0000:01:00.0: failed to receive control response completion, polling.. ath11k_pci 0000:01:00.0: Service connect timeout ath11k_pci 0000:01:00.0: failed to connect to HTT: -110 ath11k_pci 0000:01:00.0: failed to start core: -110 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM ath11k_pci 0000:01:00.0: already resetting count 2 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]2) At this point reconfiguration fails (we have 2 resets) and ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized flag and attempts to dump srng stats: Last interrupt received for each group: ath11k_pci 0000:01:00.0: group_id 0 66785ms before ath11k_pci 0000:01:00.0: group_id 1 14485062ms before ath11k_pci 0000:01:00.0: group_id 2 14485062ms before ath11k_pci 0000:01:00.0: group_id 3 14485062ms before ath11k_pci 0000:01:00.0: group_id 4 14780845ms before ath11k_pci 0000:01:00.0: group_id 5 14780845ms before ath11k_pci 0000:01:00.0: group_id 6 14485062ms before ath11k_pci 0000:01:00.0: group_id 7 66814ms before ath11k_pci 0000:01:00.0: group_id 8 68997ms before ath11k_pci 0000:01:00.0: group_id 9 67588ms before ath11k_pci 0000:01:00.0: group_id 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k] Call Trace: ? __die_body+0xae/0xb0 ? page_fault_oops+0x381/0x3e0 ? exc_page_fault+0x69/0xa0 ? asm_exc_page_fault+0x22/0x30 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)] worker_thread+0x389/0x930 kthread+0x149/0x170Clear per-list ->initialized flag in ath11k_hal_srng_deinit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38602 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iwlwifi: Add missing check for alloc_ordered_workqueueAdd check for the return value of alloc_ordered_workqueue since it mayreturn NULL pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38609 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Check governor before using governor->nameCommit 96ffcdf239de ("PM / devfreq: Remove redundant governor_name fromstruct devfreq") removes governor_name and uses governor->name to replaceit. But devfreq->governor may be NULL and directly usingdevfreq->governor->name may cause null pointer exception. Move the check ofgovernor to before using governor->name.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38611 Severity: Moderate CVSS3 score: 5.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38612 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: fbtft: fix potential memory leak in fbtft_framebuffer_alloc()In the error paths after fb_info structure is successfully allocated,the memory allocated in fb_deferred_io_init() for info->pagerefs is notfreed. Fix that by adding the cleanup function on the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38614 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:eventpoll: Fix semi-unbounded recursionEnsure that epoll instances can never form a graph deeper thanEP_MAX_NESTS+1 links.Currently, ep_loop_check_proc() ensures that the graph is loop-free anddoes some recursion depth checks, but those recursion depth checks don'tlimit the depth of the resulting tree for two reasons: - They don't look upwards in the tree. - If there are multiple downwards paths of different lengths, only one of the paths is actually considered for the depth check since commit 28d82dc1c4ed ("epoll: limit paths").Essentially, the current recursion depth check in ep_loop_check_proc() justserves to prevent it from recursing too deeply while checking for loops.A more thorough check is done in reverse_path_check() after the new graphedge has already been created; this checks, among other things, that nopaths going upwards from any non-epoll file with a length of more than 5edges exist. However, this check does not apply to non-epoll files.As a result, it is possible to recurse to a depth of at least roughly 500,tested on v6.15. (I am unsure if deeper recursion is possible; and this mayhave changed with commit 8c44dac8add7 ("eventpoll: Fix priority inversionproblem").)To fix it:1. In ep_loop_check_proc(), note the subtree depth of each visited node,and use subtree depths for the total depth calculation even when a subtreehas already been visited.2. Add ep_get_upwards_depth_proc() for similarly determining the maximumdepth of an upwards walk.3. In ep_loop_check(), use these values to limit the total path lengthbetween epoll nodes to EP_MAX_NESTS edges.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38622 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: drop UFO packets in udp_rcv_segment()When sending a packet with virtio_net_hdr to tun device, if the gso_typein virtio_net_hdr is SKB_GSO_UDP and the gso_size is less than udphdrsize, below crash may happen. ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:4572! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 62 Comm: mytest Not tainted 6.16.0-rc7 #203 PREEMPT(voluntary) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:skb_pull_rcsum+0x8e/0xa0 Code: 00 00 5b c3 cc cc cc cc 8b 93 88 00 00 00 f7 da e8 37 44 38 00 f7 d8 89 83 88 00 00 00 48 8b 83 c8 00 00 00 5b c3 cc cc cc cc <0f> 0b 0f 0b 66 66 2e 0f 1f 84 00 000 RSP: 0018:ffffc900001fba38 EFLAGS: 00000297 RAX: 0000000000000004 RBX: ffff8880040c1000 RCX: ffffc900001fb948 RDX: ffff888003e6d700 RSI: 0000000000000008 RDI: ffff88800411a062 RBP: ffff8880040c1000 R08: 0000000000000000 R09: 0000000000000001 R10: ffff888003606c00 R11: 0000000000000001 R12: 0000000000000000 R13: ffff888004060900 R14: ffff888004050000 R15: ffff888004060900 FS: 000000002406d3c0(0000) GS:ffff888084a19000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000040 CR3: 0000000004007000 CR4: 00000000000006f0 Call Trace: udp_queue_rcv_one_skb+0x176/0x4b0 net/ipv4/udp.c:2445 udp_queue_rcv_skb+0x155/0x1f0 net/ipv4/udp.c:2475 udp_unicast_rcv_skb+0x71/0x90 net/ipv4/udp.c:2626 __udp4_lib_rcv+0x433/0xb00 net/ipv4/udp.c:2690 ip_protocol_deliver_rcu+0xa6/0x160 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x72/0x90 net/ipv4/ip_input.c:233 ip_sublist_rcv_finish+0x5f/0x70 net/ipv4/ip_input.c:579 ip_sublist_rcv+0x122/0x1b0 net/ipv4/ip_input.c:636 ip_list_rcv+0xf7/0x130 net/ipv4/ip_input.c:670 __netif_receive_skb_list_core+0x21d/0x240 net/core/dev.c:6067 netif_receive_skb_list_internal+0x186/0x2b0 net/core/dev.c:6210 napi_complete_done+0x78/0x180 net/core/dev.c:6580 tun_get_user+0xa63/0x1120 drivers/net/tun.c:1909 tun_chr_write_iter+0x65/0xb0 drivers/net/tun.c:1984 vfs_write+0x300/0x420 fs/read_write.c:593 ksys_write+0x60/0xd0 fs/read_write.c:686 do_syscall_64+0x50/0x1c0 arch/x86/entry/syscall_64.c:63 To trigger gso segment in udp_queue_rcv_skb(), we should also set optionUDP_ENCAP_ESPINUDP to enable udp_sk(sk)->encap_rcv. When the encap_rcvhook return 1 in udp_queue_rcv_one_skb(), udp_csum_pull_header() will tryto pull udphdr, but the skb size has been segmented to gso size, whichleads to this crash.Previous commit cf329aa42b66 ("udp: cope with UDP GRO packet misdirection")introduces segmentation in UDP receive path only for GRO, which was neverintended to be used for UFO, so drop UFO packets in udp_rcv_segment().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38624 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Clean up allocated IRQs on unplugWhen the root of a nested PCIe bridge configuration is unplugged, thepnv_php driver leaked the allocated IRQ resources for the child bridges'hotplug event notifications, resulting in a panic.Fix this by walking all child buses and deallocating all its IRQ resourcesbefore calling pci_hp_remove_devices().Also modify the lifetime of the workqueue at struct pnv_php_slot::wq sothat it is only destroyed in pnv_php_free_slot(), instead ofpnv_php_disable_irq(). This is required since pnv_php_disable_irq() willnow be called by workers triggered by hot unplug interrupts, so theworkqueue needs to stay allocated.The abridged kernel panic that occurs without this patch is as follows: WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2 Call Trace: msi_device_data_release+0x34/0x9c (unreliable) release_nodes+0x64/0x13c devres_release_all+0xc0/0x140 device_del+0x2d4/0x46c pci_destroy_dev+0x5c/0x194 pci_hp_remove_devices+0x90/0x128 pci_hp_remove_devices+0x44/0x128 pnv_php_disable_slot+0x54/0xd4 power_write_file+0xf8/0x18c pci_slot_attr_store+0x40/0x5c sysfs_kf_write+0x64/0x78 kernfs_fop_write_iter+0x1b0/0x290 vfs_write+0x3bc/0x50c ksys_write+0x84/0x140 system_call_exception+0x124/0x230 system_call_vectored_common+0x15c/0x2ec[bhelgaas: tidy comments]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38634 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:power: supply: cpcap-charger: Fix null check for power_supply_get_by_nameIn the cpcap_usb_detect() function, the power_supply_get_by_name()function may return `NULL` instead of an error pointer.To prevent potential null pointer dereferences, Added a null check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38643 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()Callers of wdev_chandef() must hold the wiphy mutex.But the worker cfg80211_propagate_cac_done_wk() never takes the lock.Which triggers the warning below with the mesh_peer_connected_dfstest from hostapd and not (yet) released mac80211 code changes:WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165Modules linked in:CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cfWorkqueue: cfg80211 cfg80211_propagate_cac_done_wkStack: 00000000 00000001 ffffff00 6093267c 00000000 6002ec30 6d577c50 60037608 00000000 67e8d108 6063717b 00000000Call Trace: [<6002ec30>] ? _printk+0x0/0x98 [<6003c2b3>] show_stack+0x10e/0x11a [<6002ec30>] ? _printk+0x0/0x98 [<60037608>] dump_stack_lvl+0x71/0xb8 [<6063717b>] ? wdev_chandef+0x60/0x165 [<6003766d>] dump_stack+0x1e/0x20 [<6005d1b7>] __warn+0x101/0x20f [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<600b11a2>] ? mark_held_locks+0x5a/0x6e [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d [<60052e53>] ? unblock_signals+0x3a/0xe7 [<60052f2d>] ? um_set_signals+0x2d/0x43 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16 [<607508b2>] ? lock_is_held_type+0x207/0x21f [<6063717b>] wdev_chandef+0x60/0x165 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f [<60052f00>] ? um_set_signals+0x0/0x43 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a [<6007e460>] process_scheduled_works+0x3bc/0x60e [<6007d0ec>] ? move_linked_works+0x4d/0x81 [<6007d120>] ? assign_work+0x0/0xaa [<6007f81f>] worker_thread+0x220/0x2dc [<600786ef>] ? set_pf_worker+0x0/0x57 [<60087c96>] ? to_kthread+0x0/0x43 [<6008ab3c>] kthread+0x2d3/0x2e2 [<6007f5ff>] ? worker_thread+0x0/0x2dc [<6006c05b>] ? calculate_sigpending+0x0/0x56 [<6003b37d>] new_thread_handler+0x4a/0x64irq event stamp: 614611hardirqs last enabled at (614621): [<00000000600bc96b>] __up_console_sem+0x82/0xafhardirqs last disabled at (614630): [<00000000600bc92c>] __up_console_sem+0x43/0xafsoftirqs last enabled at (614268): [<00000000606c55c6>] __ieee80211_wake_queue+0x933/0x985softirqs last disabled at (614266): [<00000000606c52d6>] __ieee80211_wake_queue+0x643/0x985

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38645 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Check device memory pointer before usageAdd a NULL check before accessing device memory to prevent a crash ifdev->dm allocation in mlx5_init_once() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38663 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: reject invalid file types when reading inodesTo prevent inodes with invalid file types from tripping through the vfsand causing malfunctions or assertion failures, add a missing sanity checkwhen reading an inode from a block device. If the file type is not valid,treat it as a filesystem error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38665 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: netlink: can_changelink(): fix NULL pointer deref of struct can_priv::do_set_modeAndrei Lalaev reported a NULL pointer deref when a CAN device isrestarted from Bus Off and the driver does not implement the structcan_priv::do_set_mode callback.There are 2 code path that call struct can_priv::do_set_mode:- directly by a manual restart from the user space, via can_changelink()- delayed automatic restart after bus off (deactivated by default)To prevent the NULL pointer deference, refuse a manual restart orconfigure the automatic restart delay in can_changelink() and reportthe error via extack to user space.As an additional safety measure let can_restart() return an error ifcan_priv::do_set_mode is not set instead of dereferencing itunchecked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38668 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: fix NULL dereference on unbind due to stale coupling dataFailing to reset coupling_desc.n_coupled after freeing coupled_rdevs canlead to NULL pointer dereference when regulators are accessed post-unbind.This can happen during runtime PM or other regulator operations that relyon coupling metadata.For example, on ridesx4, unbinding the 'reg-dummy' platform device triggersa panic in regulator_lock_recursive() due to stale coupling state.Ensure n_coupled is set to 0 to prevent access to invalid pointers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38670 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to changeto different stacks along with the Shadow Call Stack if it is enabled.Those two stack changes cannot be done atomically and both functionscan be interrupted by SErrors or Debug Exceptions which, though unlikely,is very much broken : if interrupted, we can end up with mismatched stacksand Shadow Call Stack leading to clobbered stacks.In `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,but x18 stills points to the old task's SCS. When the interrupt handlertries to save the task's SCS pointer, it will save the old taskSCS pointer (x18) into the new task struct (pointed to by SP_EL0),clobbering it.In `call_on_irq_stack()`, it can happen when switching from the task stackto the IRQ stack and when switching back. In both cases, we can beinterrupted when the SCS pointer points to the IRQ SCS, but SP points tothe task stack. The nested interrupt handler pushes its return addresseson the IRQ SCS. It then detects that SP points to the task stack,calls `call_on_irq_stack()` and clobbers the task SCS pointer withthe IRQ SCS pointer, which it will also use !This leads to tasks returning to addresses on the wrong SCS,or even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACKor FPAC if enabled.This is possible on a default config, but unlikely.However, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked andinstead the GIC is responsible for filtering what interrupts the CPUshould receive based on priority.Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPUeven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*frequently depending on the system configuration and workload, leadingto unpredictable kernel panics.Completely mask DAIF in `cpu_switch_to()` and restore it when returning.Do the same in `call_on_irq_stack()`, but restore and mask aroundthe branch.Mask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistencyof behaviour between all configurations.Introduce and use an assembly macro for saving and masking DAIF,as the existing one saves but only masks IF.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38671 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: qup: jump out of the loop in case of timeoutOriginal logic only sets the return value but doesn't jump out of theloop if the bus is kept active by a client. This is not expected. Amalicious or buggy i2c client can hang the kernel in this case andshould be avoided. This is observed during a long time test with aPCA953x GPIO extender.Fix it by changing the logic to not only sets the return value, but alsojumps out of the loop and return to the caller with -ETIMEDOUT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38679 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Fix OOB read due to missing payload bound checkCurrently, The event_seq_changed() handler processes a variable numberof properties sent by the firmware. The number of properties is indicatedby the firmware and used to iterate over the payload. However, thepayload size is not being validated against the actual message length.This can lead to out-of-bounds memory access if the firmware provides aproperty count that exceeds the data available in the payload. Such acondition can result in kernel crashes or potential information leaks ifmemory beyond the buffer is accessed.Fix this by properly validating the remaining size of the payload beforeeach property access and updating bounds accordingly as properties areparsed.This ensures that property parsing is safely bounded within the receivedmessage buffer and protects against malformed or malicious firmwarebehavior.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38680 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: uvcvideo: Fix 1-byte out-of-bounds read in uvc_parse_format()The buffer length check before calling uvc_parse_format() only ensuredthat the buffer has at least 3 bytes (buflen > 2), buf the functionaccesses buffer[3], requiring at least 4 bytes.This can lead to an out-of-bounds read if the buffer has exactly 3 bytes.Fix it by checking that the buffer has at least 4 bytes inuvc_parse_format().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38681 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Memory hot remove unmaps and tears down various kernel page table regionsas required. The ptdump code can race with concurrent modifications ofthe kernel page tables. When leaf entries are modified concurrently, thedump code may log stale or inconsistent information for a VA range, butthis is otherwise not harmful.But when intermediate levels of kernel page table are freed, the dump codewill continue to use memory that has been freed and potentiallyreallocated for another purpose. In such cases, the ptdump code maydereference bogus addresses, leading to a number of potential problems.To avoid the above mentioned race condition, platforms such as arm64,riscv and s390 take memory hotplug lock, while dumping kernel page tablevia the sysfs interface /sys/kernel/debug/kernel_page_tables.Similar race condition exists while checking for pages that might havebeen marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pageswhich in turn calls ptdump_check_wx(). Instead of solving this racecondition again, let's just move the memory hotplug lock inside genericptdump_check_wx() which will benefit both the scenarios.Drop get_online_mems() and put_online_mems() combination from all existingplatform ptdump code paths.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: use old 'nbands' while purging unused classesShuang reported sch_ets test-case [1] crashing in ets_class_qlen_notify()after recent changes from Lion [2]. The problem is: in ets_qdisc_change()we purge unused DWRR queues; the value of 'q->nbands' is the new one, andthe cleanup should be done with the old one. The problem is here since myfirst attempts to fix ets_qdisc_change(), but it surfaced again after therecent qdisc len accounting fixes. Fix it purging idle DWRR queues beforeassigning a new value of 'q->nbands', so that all purge operations find aconsistent configuration: - old 'q->nbands' because it's needed by ets_class_find() - old 'q->nstrict' because it's needed by ets_class_is_strict() BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 62 UID: 0 PID: 39457 Comm: tc Kdump: loaded Not tainted 6.12.0-116.el10.x86_64 #1 PREEMPT(voluntary) Hardware name: Dell Inc. PowerEdge R640/06DKY5, BIOS 2.12.2 07/09/2021 RIP: 0010:__list_del_entry_valid_or_report+0x4/0x80 Code: ff 4c 39 c7 0f 84 39 19 8e ff b8 01 00 00 00 c3 cc cc cc cc 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <48> 8b 17 48 8b 4f 08 48 85 d2 0f 84 56 19 8e ff 48 85 c9 0f 84 ab RSP: 0018:ffffba186009f400 EFLAGS: 00010202 RAX: 00000000000000d6 RBX: 0000000000000000 RCX: 0000000000000004 RDX: ffff9f0fa29b69c0 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffffffc12c2400 R08: 0000000000000008 R09: 0000000000000004 R10: ffffffffffffffff R11: 0000000000000004 R12: 0000000000000000 R13: ffff9f0f8cfe0000 R14: 0000000000100005 R15: 0000000000000000 FS: 00007f2154f37480(0000) GS:ffff9f269c1c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001530be001 CR4: 00000000007726f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ets_class_qlen_notify+0x65/0x90 [sch_ets] qdisc_tree_reduce_backlog+0x74/0x110 ets_qdisc_change+0x630/0xa40 [sch_ets] __tc_modify_qdisc.constprop.0+0x216/0x7f0 tc_modify_qdisc+0x7c/0x120 rtnetlink_rcv_msg+0x145/0x3f0 netlink_rcv_skb+0x53/0x100 netlink_unicast+0x245/0x390 netlink_sendmsg+0x21b/0x470 ____sys_sendmsg+0x39d/0x3d0 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x7d/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f2155114084 Code: 89 02 b8 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 80 3d 25 f0 0c 00 00 74 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 89 54 24 1c 48 89 RSP: 002b:00007fff1fd7a988 EFLAGS: 00000202 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000560ec063e5e0 RCX: 00007f2155114084 RDX: 0000000000000000 RSI: 00007fff1fd7a9f0 RDI: 0000000000000003 RBP: 00007fff1fd7aa60 R08: 0000000000000010 R09: 000000000000003f R10: 0000560ee9b3a010 R11: 0000000000000202 R12: 00007fff1fd7aae0 R13: 000000006891ccde R14: 0000560ec063e5e0 R15: 00007fff1fd7aad0 [1] https://lore.kernel.org/netdev/e08c7f4a6882f260011909a868311c6e9b54f3e4.1639153474.git.dcaratti@redhat.com/ [2] https://lore.kernel.org/netdev/d912cbd7-193b-4269-9857-525bee8bbb6a@gmail.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38687 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix race between polling and detachingsyzbot reports a use-after-free in comedi in the below link, which isdue to comedi gladly removing the allocated async area even though pollrequests are still active on the wait_queue_head inside of it. This cancause a use-after-free when the poll entries are later triggered orremoved, as the memory for the wait_queue_head has been freed. We needto check there are no tasks queued on any of the subdevices' wait queuesbefore allowing the device to be detached by the `COMEDI_DEVCONFIG`ioctl.Tasks will read-lock `dev->attach_lock` before adding themselves to thesubdevice wait queue, so fix the problem in the `COMEDI_DEVCONFIG` ioctlhandler by write-locking `dev->attach_lock` before checking that all ofthe subdevices are safe to be deleted. This includes testing for anysleepers on the subdevices' wait queues. It remains locked until thedevice has been detached. This requires the `comedi_device_detach()`function to be refactored slightly, moving the bulk of it into newfunction `comedi_device_detach_locked()`.Note that the refactor of `comedi_device_detach()` results in`comedi_device_cancel_all()` now being called while `dev->attach_lock`is write-locked, which wasn't the case previously, but that does notmatter.Thanks to Jens Axboe for diagnosing the problem and co-developing thispatch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38691 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pNFS: Fix uninited ptr deref in block/scsi layoutThe error occurs on the third attempt to encode extents. When functionext_tree_prepare_commit() reallocates a larger buffer to retry encodingextents, the "layoutupdate_pages" page array is initialized only after theretry loop. But ext_tree_free_commitdata() is called on every iterationand tries to put pages in the array, thus dereferencing uninitializedpointers.An additional problem is that there is no limit on the maximum possiblebuffer_size. When there are too many extents, the client may create alayoutcommit that is larger than the maximum possible RPC size acceptedby the server.During testing, we observed two typical scenarios. First, one memory pagefor extents is enough when we work with small files, append data to theend of the file, or preallocate extents before writing. But when we filla new large file without preallocating, the number of extents can be huge,and counting the number of written extents in ext_tree_encode_commit()does not help much. Since this number increases even more betweenunlocking and locking of ext_tree, the reallocated buffer may not belarge enough again and again.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: w7090p: fix null-ptr-deref in w7090p_tuner_write_serpar and w7090p_tuner_read_serparIn w7090p_tuner_write_serpar, msg is controlled by user. When msg[0].buf is null and msg[0].len is zero, former checks on msg[0].buf would be passed. If accessing msg[0].buf[2] without sanity check, null pointer deref would happen. We addcheck on msg[0].len to prevent crash.Similar commit: commit 0ed554fd769a ("media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix null pointer accessWriting a string without delimiters (' ', '\n', '\0') to the undergpu_od/fan_ctrl sysfs or pp_power_profile_mode for the CUSTOM profilewill result in a null pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38712 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: don't use BUG_ON() in hfsplus_create_attributes_file()When the volume header contains erroneous values that do not reflectthe actual state of the filesystem, hfsplus_fill_super() assumes thatthe attributes file is not yet created, which later results in hittingBUG_ON() when hfsplus_create_attributes_file() is called. Replace thisBUG_ON() with -EIO error with a message to suggest running fsck tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38717 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: kcm: Fix race condition in kcm_unattach()syzbot found a race condition when kcm_unattach(psock)and kcm_release(kcm) are executed at the same time.kcm_unattach() is missing a check of the flagkcm->tx_stopped before calling queue_work().If the kcm has a reserved psock, kcm_unattach() might get executedbetween cancel_work_sync() and unreserve_psock() in kcm_release(),requeuing kcm->tx_work right before kcm gets freed in kcm_done().Remove kcm->tx_stopped and replace it by the lesserror-prone disable_work_sync().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38718 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: linearize cloned gso packets in sctp_rcvA cloned head skb still shares these frag skbs in fraglist with theoriginal head skb. It's not safe to access these frag skbs.syzbot reported two use-of-uninitialized-memory bugs caused by this: BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211 sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122 __release_sock+0x1da/0x330 net/core/sock.c:3106 release_sock+0x6b/0x250 net/core/sock.c:3660 sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360 sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885 sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031 inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:718 [inline]and BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987 sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88 sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331 sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148 __release_sock+0x1d3/0x330 net/core/sock.c:3213 release_sock+0x6b/0x270 net/core/sock.c:3767 sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367 sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886 sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032 inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851 sock_sendmsg_nosec net/socket.c:712 [inline]This patch fixes it by linearizing cloned gso packets in sctp_rcv().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: fix refcount leak on table dumpThere is a reference count leak in ctnetlink_dump_table(): if (res < 0) { nf_conntrack_get(&ct->ct_general); // HERE cb->args[1] = (unsigned long)ct; ...While its very unlikely, its possible that ct == last.If this happens, then the refcount of ct was already incremented.This 2nd increment is never undone.This prevents the conntrack object from being released, which in turnkeeps prevents cnet->count from dropping back to 0.This will then block the netns dismantle (or conntrack rmmod) asnf_conntrack_cleanup_net_list() will wait forever.This can be reproduced by running conntrack_resize.sh selftest in a loop.It takes ~20 minutes for me on a preemptible kernel on average beforeI see a runaway kworker spinning in nf_conntrack_cleanup_net_list.One fix would to change this to: if (res < 0) { if (ct != last) nf_conntrack_get(&ct->ct_general);But this reference counting isn't needed in the first place.We can just store a cookie value instead.A followup patch will do the same for ctnetlink_exp_dump_table,it looks to me as if this has the same problem and likectnetlink_dump_table, we only need a 'skip hint', not the actualobject so we can apply the same cookie strategy there as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: handle get_client_locked() failure in nfsd4_setclientid_confirm()Lei Lu recently reported that nfsd4_setclientid_confirm() did not checkthe return value from get_client_locked(). a SETCLIENTID_CONFIRM couldrace with a confirmed client expiring and fail to get a reference. Thatcould later lead to a UAF.Fix this by getting a reference early in the case where there is anextant confirmed client. If that fails then treat it as if there were noconfirmed client found at all.In the case where the unconfirmed client is expiring, just fail andreturn the result from get_client_locked().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix_devices: add phy_mask for ax88772 mdio busWithout setting phy_mask for ax88772 mdio bus, current driver may createat most 32 mdio phy devices with phy address range from 0x00 ~ 0x1f.DLink DUB-E100 H/W Ver B1 is such a device. However, only one main phydevice will bind to net phy driver. This is creating issue during systemsuspend/resume since phy_polling_mode() in phy_state_machine() willdirectly deference member of phydev->drv for non-main phy devices. ThenNULL pointer dereference issue will occur. Due to only external phy orinternal phy is necessary, add phy_mask for ax88772 mdio bus to workarnoudthe issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb3: fix for slab out of bounds on mount to ksmbdWith KASAN enabled, it is possible to get a slab out of boundsduring mount to ksmbd due to missing check in parse_server_interfaces()(see below): BUG: KASAN: slab-out-of-bounds in parse_server_interfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827 CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: dump_stack_lvl+0x9f/0xf0 print_report+0xd1/0x670 __virt_addr_valid+0x22c/0x430 ? parse_server_interfaces+0x14ee/0x1880 [cifs] ? kasan_complete_mode_report_info+0x2a/0x1f0 ? parse_server_interfaces+0x14ee/0x1880 [cifs] kasan_report+0xd6/0x110 parse_server_interfaces+0x14ee/0x1880 [cifs] __asan_report_load_n_noabort+0x13/0x20 parse_server_interfaces+0x14ee/0x1880 [cifs] ? __pfx_parse_server_interfaces+0x10/0x10 [cifs] ? trace_hardirqs_on+0x51/0x60 SMB3_request_interfaces+0x1ad/0x3f0 [cifs] ? __pfx_SMB3_request_interfaces+0x10/0x10 [cifs] ? SMB2_tcon+0x23c/0x15d0 [cifs] smb3_qfs_tcon+0x173/0x2b0 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] ? cifs_get_tcon+0x105d/0x2120 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_get_tcon+0x105d/0x2120 [cifs] ? __pfx_smb3_qfs_tcon+0x10/0x10 [cifs] cifs_mount_get_tcon+0x369/0xb90 [cifs] ? dfs_cache_find+0xe7/0x150 [cifs] dfs_mount_share+0x985/0x2970 [cifs] ? check_path.constprop.0+0x28/0x50 ? save_trace+0x54/0x370 ? __pfx_dfs_mount_share+0x10/0x10 [cifs] ? __lock_acquire+0xb82/0x2ba0 ? __kasan_check_write+0x18/0x20 cifs_mount+0xbc/0x9e0 [cifs] ? __pfx_cifs_mount+0x10/0x10 [cifs] ? do_raw_spin_unlock+0x5d/0x200 ? cifs_setup_cifs_sb+0x29d/0x810 [cifs] cifs_smb3_do_mount+0x263/0x1990 [cifs]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38729 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 power domain descriptors, tooUAC3 power domain descriptors need to be verified with its variablebLength for avoiding the unexpected OOB accesses by maliciousfirmware, too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38735 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:gve: prevent ethtool ops after shutdownA crash can occur if an ethtool operation is invokedafter shutdown() is called.shutdown() is invoked during system shutdown to stop DMA operationswithout performing expensive deallocations. It is discouraged tounregister the netdev in this path, so the device may still be visibleto userspace and kernel helpers.In gve, shutdown() tears down most internal data structures. If anethtool operation is dispatched after shutdown(), it will dereferencefreed or NULL pointers, leading to a kernel panic. While gracefulshutdown normally quiesces userspace before invoking the rebootsyscall, forced shutdowns (as observed on GCP VMs) can still triggerthis path.Fix by calling netif_device_detach() in shutdown().This marks the device as detached so the ethtool ioctl handlerwill skip dispatching operations to the driver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39673 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix race conditions in ppp_fill_forward_pathppp_fill_forward_path() has two race conditions:1. The ppp->channels list can change between list_empty() and list_first_entry(), as ppp_lock() is not held. If the only channel is deleted in ppp_disconnect_channel(), list_first_entry() may access an empty head or a freed entry, and trigger a panic.2. pch->chan can be NULL. When ppp_unregister_channel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.Fix these by using a lockless RCU approach:- Use list_first_or_null_rcu() to safely test and access the first list entry.- Convert list modifications on ppp->channels to their RCU variants and add synchronize_net() after removal.- Check for a NULL pch->chan before dereferencing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39675 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()The function mod_hdcp_hdcp1_create_session() calls the functionget_first_active_display(), but does not check its return value.The return value is a null pointer if the display list is empty.This will lead to a null pointer dereference.Add a null pointer check for get_first_active_display() and returnMOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.This is similar to the commit c3e9826a2202("drm/amd/display: Add null pointer check for get_first_active_display()").(cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39676 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla4xxx: Prevent a potential error pointer dereferenceThe qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,but qla4xxx_ep_connect() returns error pointers. Propagating the errorpointers will lead to an Oops in the caller, so change the error pointersto NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39677 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix backlog accounting in qdisc_dequeue_internalThis issue applies for the following qdiscs: hhf, fq, fq_codel, andfq_pie, and occurs in their change handlers when adjusting to the newlimit. The problem is the following in the values passed to thesubsequent qdisc_tree_reduce_backlog call given a tbf parent: When the tbf parent runs out of tokens, skbs of these qdiscs will be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued, which accounts for both qlen and backlog. However, in the case of qdisc_dequeue_internal, ONLY qlen is accounted for when pulling from gso_skb. This means that these qdiscs are missing a qdisc_qstats_backlog_dec when dropping packets to satisfy the new limit in their change handlers. One can observe this issue with the following (with tc patched to support a limit of 0): export TARGET=fq tc qdisc del dev lo root tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000 echo ''; echo 'add child'; tc -s -d qdisc show dev lo ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null echo ''; echo 'after ping'; tc -s -d qdisc show dev lo tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0 echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo tc qdisc replace dev lo handle 2: parent 1:1 sfq echo ''; echo 'post graft'; tc -s -d qdisc show dev lo The second to last show command shows 0 packets but a positive number (74) of backlog bytes. The problem becomes clearer in the last show command, where qdisc_purge_queue triggers qdisc_tree_reduce_backlog with the positive backlog and causes an underflow in the tbf parent's backlog (4096 Mb instead of 0).To fix this issue, the codepath for all clients of qdisc_dequeue_internalhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.qdisc_dequeue_internal handles the backlog adjustments for all cases thatdo not directly use the dequeue handler.The old fq_codel_change limit adjustment loop accumulated the arguments tothe subsequent qdisc_tree_reduce_backlog call through the cstats field.However, this is confusing and error prone as fq_codel_dequeue could alsopotentially mutate this field (which qdisc_dequeue_internal calls in thenon gso_skb case), so we have unified the code here with other qdiscs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39681 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helperSince 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")resctrl_cpu_detect() has been moved from common CPU initialization code tothe vendor-specific BSP init helper, while Hygon didn't put that call in theircode.This triggers a division by zero fault during early booting stage on ourmachines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() triesto calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.Add the missing resctrl_cpu_detect() in the Hygon BSP init helper. [ bp: Massage commit message. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39683 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Limit access to parser->buffer when trace_get_user failedWhen the length of the string written to set_ftrace_filter exceedsFTRACE_BUFF_MAX, the following KASAN alarm will be triggered:BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0Read of size 1 at addr ffff0000d00bd5ba by task ash/165CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirtyHardware name: linux,dummy-virt (DT)Call trace: show_stack+0x34/0x50 (C) dump_stack_lvl+0xa0/0x158 print_address_description.constprop.0+0x88/0x398 print_report+0xb0/0x280 kasan_report+0xa4/0xf0 __asan_report_load1_noabort+0x20/0x30 strsep+0x18c/0x1b0 ftrace_process_regex.isra.0+0x100/0x2d8 ftrace_regex_release+0x484/0x618 __fput+0x364/0xa58 ____fput+0x28/0x40 task_work_run+0x154/0x278 do_notify_resume+0x1f0/0x220 el0_svc+0xec/0xf0 el0t_64_sync_handler+0xa0/0xe8 el0t_64_sync+0x1ac/0x1b0The reason is that trace_get_user will fail when processing a stringlonger than FTRACE_BUFF_MAX, but not set the end of parser->buffer to 0.Then an OOB access will be triggered in ftrace_regex_release->ftrace_process_regex->strsep->strpbrk. We can solve this problem bylimiting access to parser->buffer when trace_get_user failed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39684 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized memory in do_insn_ioctl() and do_insnlist_ioctl()syzbot reports a KMSAN kernel-infoleak in `do_insn_ioctl()`. A kernelbuffer is allocated to hold `insn->n` samples (each of which is an`unsigned int`). For some instruction types, `insn->n` samples arecopied back to user-space, unless an error code is being returned. Theproblem is that not all the instruction handlers that need to returndata to userspace fill in the whole `insn->n` samples, so that there isan information leak. There is a similar syzbot report for`do_insnlist_ioctl()`, although it does not have a reproducer for it atthe time of writing.One culprit is `insn_rw_emulate_bits()` which is used as the handler for`INSN_READ` or `INSN_WRITE` instructions for subdevices that do not havea specific handler for that instruction, but do have an `INSN_BITS`handler. For `INSN_READ` it only fills in at most 1 sample, so if`insn->n` is greater than 1, the remaining `insn->n - 1` samples copiedto userspace will be uninitialized kernel data.Another culprit is `vm80xx_ai_insn_read()` in the "vm80xx" driver. Itnever returns an error, even if it fails to fill the buffer.Fix it in `do_insn_ioctl()` and `do_insnlist_ioctl()` by making surethat uninitialized parts of the allocated buffer are zeroed beforehandling each instruction.Thanks to Arnaud Lecomte for their fix to `do_insn_ioctl()`. That fixreplaced the call to `kmalloc_array()` with `kcalloc()`, but it is notalways necessary to clear the whole buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39686 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Make insn_rw_emulate_bits() do insn->n samplesThe `insn_rw_emulate_bits()` function is used as a default handler for`INSN_READ` instructions for subdevices that have a handler for`INSN_BITS` but not for `INSN_READ`. Similarly, it is used as a defaulthandler for `INSN_WRITE` instructions for subdevices that have a handlerfor `INSN_BITS` but not for `INSN_WRITE`. It works by emulating the`INSN_READ` or `INSN_WRITE` instruction handling with a constructed`INSN_BITS` instruction. However, `INSN_READ` and `INSN_WRITE`instructions are supposed to be able read or write multiple samples,indicated by the `insn->n` value, but `insn_rw_emulate_bits()` currentlyonly handles a single sample. For `INSN_READ`, the comedi core willcopy `insn->n` samples back to user-space. (That triggered KASANkernel-infoleak errors when `insn->n` was greater than 1, but that isbeing fixed more generally elsewhere in the comedi core.)Make `insn_rw_emulate_bits()` either handle `insn->n` samples, or returnan error, to conform to the general expectation for `INSN_READ` and`INSN_WRITE` handlers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39687 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: as73211: Ensure buffer holes are zeroedGiven that the buffer is copied to a kfifo that ultimately user spacecan read, ensure we zero it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39689 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Also allocate and copy hash for reading of filter filesCurrently the reader of set_ftrace_filter and set_ftrace_notrace just addsthe pointer to the global tracer hash to its iterator. Unlike the writerthat allocates a copy of the hash, the reader keeps the pointer to thefilter hashes. This is problematic because this pointer is static acrossfunction calls that release the locks that can update the global tracerhashes. This can cause UAF and similar bugs.Allocate and copy the hash for reading the filter files like it is donefor the writers. This not only fixes UAF bugs, but also makes the code abit simpler as it doesn't have to differentiate when to free theiterator's hash between writers and readers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39693 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Avoid a NULL pointer dereference[WHY]Although unlikely drm_atomic_get_new_connector_state() ordrm_atomic_get_old_connector_state() can return NULL.[HOW]Check returns before dereference.(cherry picked from commit 1e5e8d672fec9f2ab352be121be971877bff2af9)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39697 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a race when updating an existing writeAfter nfs_lock_and_join_requests() tests for whether the request isstill attached to the mapping, nothing prevents a call tonfs_inode_remove_request() from succeeding until we actually lock thepage group.The reason is that whoever called nfs_inode_remove_request() doesn'tnecessarily have a lock on the page group head.So in order to avoid races, let's take the page group lock earlier innfs_lock_and_join_requests(), and hold it across the removal of therequest in nfs_inode_remove_request().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39702 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: Fix MAC comparison to be constant-timeTo prevent timing attacks, MACs need to be compared in constant time.Use the appropriate helper function for this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39705 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix a Null pointer dereference vulnerability[Why]A null pointer dereference vulnerability exists in the AMD display driver's(DC module) cleanup function dc_destruct().When display control context (dc->ctx) construction fails(due to memory allocation failure), this pointer remains NULL.During subsequent error handling when dc_destruct() is called,there's no NULL check before dereferencing the perf_trace member(dc->ctx->perf_trace), causing a kernel null pointer dereference crash.[How]Check if dc->ctx is non-NULL before dereferencing.(Updated commit text and removed unnecessary error message)(cherry picked from commit 9dd8e2ba268c636c240a918e0a31e6feaee19404)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39709 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: protect against spurious interrupts during probeMake sure the interrupt handler is initialized before the interrupt isregistered.If the IRQ is registered before hfi_create(), it's possible that aninterrupt fires before the handler setup is complete, leading to a NULLdereference.This error condition has been observed during system boot on Rb3Gen2.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39710 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: venus: Add a check for packet size after reading from shared memoryAdd a check to ensure that the packet size does not exceed the number ofavailable words after reading the packet header from shared memory. Thisensures that the size provided by the firmware is safe to process andprevent potential out-of-bounds memory access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39713 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: rainshadow-cec: fix TOCTOU race condition in rain_interrupt()In the interrupt handler rain_interrupt(), the buffer full check onrain->buf_len is performed before acquiring rain->buf_lock. Thiscreates a Time-of-Check to Time-of-Use (TOCTOU) race condition, asrain->buf_len is concurrently accessed and modified in the workhandler rain_irq_work_handler() under the same lock.Multiple interrupt invocations can race, with each reading buf_lenbefore it becomes full and then proceeding. This can lead to bothinterrupts attempting to write to the buffer, incrementing buf_lenbeyond its capacity (DATA_SIZE) and causing a buffer overflow.Fix this bug by moving the spin_lock() to before the buffer fullcheck. This ensures that the check and the subsequent buffer modificationare performed atomically, preventing the race condition. An correspondingspin_unlock() is added to the overflow path to correctly release thelock.This possible bug was found by an experimental static analysis tooldeveloped by our team.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39714 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: usbtv: Lock resolution while streamingWhen an program is streaming (ffplay) and another program (qv4l2)changes the TV standard from NTSC to PAL, the kernel crashes due to tryingto copy to unmapped memory.Changing from NTSC to PAL increases the resolution in the usbtv struct,but the video plane buffer isn't adjusted, so it overflows.[hverkuil: call vb2_is_busy instead of vb2_is_streaming]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39721 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: qat - flush misc workqueue during device shutdownRepeated loading and unloading of a device specific QAT driver, forexample qat_4xxx, in a tight loop can lead to a crash due to ause-after-free scenario. This occurs when a power management (PM)interrupt triggers just before the device-specific driver (e.g.,qat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remainsloaded.Since the driver uses a shared workqueue (`qat_misc_wq`) across alldevices and owned by intel_qat.ko, a deferred routine from thedevice-specific driver may still be pending in the queue. If thisroutine executes after the driver is unloaded, it can dereference freedmemory, resulting in a page fault and kernel crash like the following: BUG: unable to handle page fault for address: ffa000002e50a01c #PF: supervisor read access in kernel mode RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat] Call Trace: pm_bh_handler+0x1d2/0x250 [intel_qat] process_one_work+0x171/0x340 worker_thread+0x277/0x3a0 kthread+0xf0/0x120 ret_from_fork+0x2d/0x50To prevent this, flush the misc workqueue during device shutdown toensure that all pending work items are completed before the driver isunloaded.Note: This approach may slightly increase shutdown latency if theworkqueue contains jobs from other devices, but it ensures correctnessand stability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:serial: 8250: fix panic due to PSLVERRWhen the PSLVERR_RESP_EN parameter is set to 1, the device generatesan error response if an attempt is made to read an empty RBR (ReceiveBuffer Register) while the FIFO is enabled.In serial8250_do_startup(), calling serial_port_out(port, UART_LCR,UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokesdw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latterfunction enables the FIFO via serial_out(p, UART_FCR, p->fcr).Execution proceeds to the serial_port_in(port, UART_RX).This satisfies the PSLVERR trigger condition.When another CPU (e.g., using printk()) is accessing the UART (UARTis busy), the current CPU fails the check (value & ~UART_LCR_SPAR) ==(lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enterdw8250_force_idle().Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lockto fix this issue.Panic backtrace:[ 0.442336] Oops - unknown exception [#1][ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a[ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e...[ 0.442416] console_on_rootfs+0x26/0x70

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39728 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:clk: samsung: Fix UBSAN panic in samsung_clk_init()With UBSAN_ARRAY_BOUNDS=y, I'm hitting the below panic due todereferencing `ctx->clk_data.hws` before setting`ctx->clk_data.num = nr_clks`. Move that up to fix the crash. UBSAN: array index out of bounds: 00000000f2005512 [#1] PREEMPT SMP Call trace: samsung_clk_init+0x110/0x124 (P) samsung_clk_init+0x48/0x124 (L) samsung_cmu_register_one+0x3c/0xa0 exynos_arm64_register_cmu+0x54/0x64 __gs101_cmu_top_of_clk_init_declare+0x28/0x60 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39730 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix filehandle bounds checking in nfs_fh_to_dentry()The function needs to check the minimal filehandle length before it canaccess the embedded filehandle.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39732 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix sleeping-in-atomic in ath11k_mac_op_set_bitrate_mask()ath11k_mac_disable_peer_fixed_rate() is passed as the iterator toieee80211_iterate_stations_atomic(). Note in this case the iterator isrequired to be atomic, however ath11k_mac_disable_peer_fixed_rate() doesnot follow it as it might sleep. Consequently below warning is seen:BUG: sleeping function called from invalid context at wmi.c:304Call Trace: dump_stack_lvl __might_resched.cold ath11k_wmi_cmd_send ath11k_wmi_set_peer_param ath11k_mac_disable_peer_fixed_rate ieee80211_iterate_stations_atomic ath11k_mac_op_set_bitrate_mask.coldChange to ieee80211_iterate_stations_mtx() to fix this issue.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39744 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Fix rcu_read_unlock() deadloop due to IRQ workDuring rcu_read_unlock_special(), if this happens during irq_exit(), wecan lockup if an IPI is issued. This is because the IPI itself triggersthe irq_exit() path causing a recursive lock up.This is precisely what Xiongfeng found when invoking a BPF program onthe trace_tick_stop() tracepoint As shown in the trace below. Fix bymanaging the irq_work state correctly.irq_exit() __irq_exit_rcu() /* in_hardirq() returns false after this */ preempt_count_sub(HARDIRQ_OFFSET) tick_irq_exit() tick_nohz_irq_exit() tick_nohz_stop_sched_tick() trace_tick_stop() /* a bpf prog is hooked on this trace point */ __bpf_trace_tick_stop() bpf_trace_run2() rcu_read_unlock_special() /* will send a IPI to itself */ irq_work_queue_on(&rdp->defer_qs_iw, rdp->cpu);A simple reproducer can also be obtained by doing the following intick_irq_exit(). It will hang on boot without the patch: static inline void tick_irq_exit(void) { + rcu_read_lock(); + WRITE_ONCE(current->rcu_read_unlock_special.b.need_qs, true); + rcu_read_unlock(); +[neeraj: Apply Frederic's suggested fix for PREEMPT_RT]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39749 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Protect ->defer_qs_iw_pending from data raceOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() isinvoked within an interrupts-disabled region of code [1], it will invokercu_read_unlock_special(), which uses an irq-work handler to force thesystem to notice when the RCU read-side critical section actually ends.That end won't happen until interrupts are enabled at the soonest.In some kernels, such as those booted with rcutree.use_softirq=y, theirq-work handler is used unconditionally.The per-CPU rcu_data structure's ->defer_qs_iw_pending field isupdated by the irq-work handler and is both read and updated byrcu_read_unlock_special(). This resulted in the following KCSAN splat:------------------------------------------------------------------------BUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_specialread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8: rcu_read_unlock_special+0x175/0x260 __rcu_read_unlock+0x92/0xa0 rt_spin_unlock+0x9b/0xc0 __local_bh_enable+0x10d/0x170 __local_bh_enable_ip+0xfb/0x150 rcu_do_batch+0x595/0xc40 rcu_cpu_kthread+0x4e9/0x830 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30write to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8: rcu_preempt_deferred_qs_handler+0x1e/0x30 irq_work_single+0xaf/0x160 run_irq_workd+0x91/0xc0 smpboot_thread_fn+0x24d/0x3b0 kthread+0x3bd/0x410 ret_from_fork+0x35/0x40 ret_from_fork_asm+0x1a/0x30no locks held by irq_work/8/88.irq event stamp: 200272hardirqs last enabled at (200272): [] finish_task_switch+0x131/0x320hardirqs last disabled at (200271): [] __schedule+0x129/0xd70softirqs last enabled at (0): [] copy_process+0x4df/0x1cc0softirqs last disabled at (0): [<0000000000000000>] 0x0------------------------------------------------------------------------The problem is that irq-work handlers run with interrupts enabled, whichmeans that rcu_preempt_deferred_qs_handler() could be interrupted,and that interrupt handler might contain an RCU read-side criticalsection, which might invoke rcu_read_unlock_special(). In the strictKCSAN mode of operation used by RCU, this constitutes a data race onthe ->defer_qs_iw_pending field.This commit therefore disables interrupts across the portion of thercu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pendingfield. This suffices because this handler is not a fast path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39754 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/smaps: fix race between smaps_hugetlb_range and migrationsmaps_hugetlb_range() handles the pte without holdling ptl, and may beconcurrenct with migration, leaing to BUG_ON in pfn_swap_entry_to_page(). The race is as follows.smaps_hugetlb_range migrate_pages huge_ptep_get remove_migration_ptes folio_unlock pfn_swap_entry_folio BUG_ONTo fix it, hold ptl lock in smaps_hugetlb_range().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39756 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs: Prevent file descriptor table allocations exceeding INT_MAXWhen sysctl_nr_open is set to a very high value (for example, 1073741816as set by systemd), processes attempting to use file descriptors nearthe limit can trigger massive memory allocation attempts that exceedINT_MAX, resulting in a WARNING in mm/slub.c: WARNING: CPU: 0 PID: 44 at mm/slub.c:5027 __kvmalloc_node_noprof+0x21a/0x288This happens because kvmalloc_array() and kvmalloc() check if therequested size exceeds INT_MAX and emit a warning when the allocation isnot flagged with __GFP_NOWARN.Specifically, when nr_open is set to 1073741816 (0x3ffffff8) and aprocess calls dup2(oldfd, 1073741880), the kernel attempts to allocate:- File descriptor array: 1073741880 * 8 bytes = 8,589,935,040 bytes- Multiple bitmaps: ~400MB- Total allocation size: > 8GB (exceeding INT_MAX = 2,147,483,647)Reproducer:1. Set /proc/sys/fs/nr_open to 1073741816: # echo 1073741816 > /proc/sys/fs/nr_open2. Run a program that uses a high file descriptor: #include #include int main() { struct rlimit rlim = {1073741824, 1073741824}; setrlimit(RLIMIT_NOFILE, &rlim); dup2(2, 1073741880); // Triggers the warning return 0; }3. Observe WARNING in dmesg at mm/slub.c:5027systemd commit a8b627a introduced automatic bumping of fs.nr_open to themaximum possible value. The rationale was that systems with memorycontrol groups (memcg) no longer need separate file descriptor limitssince memory is properly accounted. However, this change overlookedthat:1. The kernel's allocation functions still enforce INT_MAX as a maximum size regardless of memcg accounting2. Programs and tests that legitimately test file descriptor limits can inadvertently trigger massive allocations3. The resulting allocations (>8GB) are impractical and will always failsystemd's algorithm starts with INT_MAX and keeps halving the valueuntil the kernel accepts it. On most systems, this results in nr_openbeing set to 1073741816 (0x3ffffff8), which is just under 1GB of filedescriptors.While processes rarely use file descriptors near this limit in normaloperation, certain selftests (liketools/testing/selftests/core/unshare_test.c) and programs that test filedescriptor limits can trigger this issue.Fix this by adding a check in alloc_fdtable() to ensure the requestedallocation size does not exceed INT_MAX. This causes the operation tofail with -EMFILE instead of triggering a kernel warning and avoids theimpractical >8GB memory allocation request.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Validate UAC3 cluster segment descriptorsUAC3 class segment descriptors need to be verified whether their sizesmatch with the declared lengths and whether they fit with theallocated buffer sizes, too. Otherwise malicious firmware may lead tothe unexpected OOB accesses.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39764 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: remove refcounting in expectation dumpersSame pattern as previous patch: do not keep the expectation objectalive via refcount, only store a cookie value and then use thatas the skip hint for dump resumption.AFAICS this has the same issue as the one resolved in the conntrackdumper, when we do if (!refcount_inc_not_zero(&exp->use))to increment the refcount, there is a chance that exp == last, whichcauses a double-increment of the refcount and subsequent memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39766 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: Make cake_enqueue return NET_XMIT_CN when past buffer_limitThe following setup can trigger a WARNING in htb_activate due tothe condition: !cl->leaf.q->q.qlentc qdisc del dev lo roottc qdisc add dev lo root handle 1: htb default 1tc class add dev lo parent 1: classid 1:1 \ htb rate 64bittc qdisc add dev lo parent 1:1 handle f: \ cake memlimit 1bping -I lo -f -c1 -s64 -W0.001 127.0.0.1This is because the low memlimit leads to a low buffer_limit, whichcauses packet dropping. However, cake_enqueue still returnsNET_XMIT_SUCCESS, causing htb_enqueue to call htb_activate with anempty child qdisc. We should return NET_XMIT_CN when packets aredropped from the same tin and flow.I do not believe return value of NET_XMIT_CN is necessary for packetdrops in the case of ack filtering, as that is meant to optimizeperformance, not to signal congestion.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39772 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/hisilicon/hibmc: fix the hibmc loaded failed bugWhen hibmc loaded failed, the driver use hibmc_unload to free theresource, but the mutexes in mode.config are not init, which willaccess an NULL pointer. Just change goto statement to return, becausehibnc_hw_init() doesn't need to free anything.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39773 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix soft lockup in br_multicast_query_expired()When set multicast_query_interval to a large value, the local variable'time' in br_multicast_send_query() may overflow. If the time is smallerthan jiffies, the timer will expire immediately, and then call mod_timer()again, which creates a loop and may trigger the following soft lockupissue. watchdog: BUG: soft lockup - CPU#1 stuck for 221s! [rb_consumer:66] CPU: 1 UID: 0 PID: 66 Comm: rb_consumer Not tainted 6.16.0+ #259 PREEMPT(none) Call Trace: __netdev_alloc_skb+0x2e/0x3a0 br_ip6_multicast_alloc_query+0x212/0x1b70 __br_multicast_send_query+0x376/0xac0 br_multicast_send_query+0x299/0x510 br_multicast_query_expired.constprop.0+0x16d/0x1b0 call_timer_fn+0x3b/0x2a0 __run_timers+0x619/0x950 run_timer_softirq+0x11c/0x220 handle_softirqs+0x18e/0x560 __irq_exit_rcu+0x158/0x1a0 sysvec_apic_timer_interrupt+0x76/0x90 This issue can be reproduced with: ip link add br0 type bridge echo 1 > /sys/class/net/br0/bridge/multicast_querier echo 0xffffffffffffffff > /sys/class/net/br0/bridge/multicast_query_interval ip link set dev br0 upThe multicast_startup_query_interval can also cause this issue. Similar tothe commit 99b40610956a ("net: bridge: mcast: add and enforce queryinterval minimum"), add check for the query interval maximum to fix thisissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39779 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: subpage: keep TOWRITE tag until folio is cleanedbtrfs_subpage_set_writeback() calls folio_start_writeback() the first timea folio is written back, and it also clears the PAGECACHE_TAG_TOWRITE tageven if there are still dirty blocks in the folio. This can break orderingguarantees, such as those required by btrfs_wait_ordered_extents().That ordering breakage leads to a real failure. For example, runninggeneric/464 on a zoned setup will hit the following ASSERT. This happensbecause the broken ordering fails to flush existing dirty pages before thefile size is truncated. assertion failed: !list_empty(&ordered->list) :: 0, in fs/btrfs/zoned.c:1899 ------------[ cut here ]------------ kernel BUG at fs/btrfs/zoned.c:1899! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 2 UID: 0 PID: 1906169 Comm: kworker/u130:2 Kdump: loaded Not tainted 6.16.0-rc6-BTRFS-ZNS+ #554 PREEMPT(voluntary) Hardware name: Supermicro Super Server/H12SSL-NT, BIOS 2.0 02/22/2021 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_finish_ordered_zoned.cold+0x50/0x52 [btrfs] RSP: 0018:ffffc9002efdbd60 EFLAGS: 00010246 RAX: 000000000000004c RBX: ffff88811923c4e0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff827e38b1 RDI: 00000000ffffffff RBP: ffff88810005d000 R08: 00000000ffffdfff R09: ffffffff831051c8 R10: ffffffff83055220 R11: 0000000000000000 R12: ffff8881c2458c00 R13: ffff88811923c540 R14: ffff88811923c5e8 R15: ffff8881c1bd9680 FS: 0000000000000000(0000) GS:ffff88a04acd0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f907c7a918c CR3: 0000000004024000 CR4: 0000000000350ef0 Call Trace: ? srso_return_thunk+0x5/0x5f btrfs_finish_ordered_io+0x4a/0x60 [btrfs] btrfs_work_helper+0xf9/0x490 [btrfs] process_one_work+0x204/0x590 ? srso_return_thunk+0x5/0x5f worker_thread+0x1d6/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0x118/0x230 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x205/0x260 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Consider process A calling writepages() with WB_SYNC_NONE. In zoned mode orfor compressed writes, it locks several folios for delalloc and startswriting them out. Let's call the last locked folio folio X. Suppose thewrite range only partially covers folio X, leaving some pages dirty.Process A calls btrfs_subpage_set_writeback() when building a bio. Thisfunction call clears the TOWRITE tag of folio X, whose size = 8K andthe block size = 4K. It is following state. 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY) <-----> Process A will write this range.Now suppose process B concurrently calls writepages() with WB_SYNC_ALL. Itcalls tag_pages_for_writeback() to tag dirty folios withPAGECACHE_TAG_TOWRITE. Since folio X is still dirty, it gets tagged. Then,B collects tagged folios using filemap_get_folios_tag() and must wait forfolio X to be written before returning from writepages(). 0 4K 8K |/////|/////| (flag: DIRTY, tag: DIRTY|TOWRITE)However, between tagging and collecting, process A may callbtrfs_subpage_set_writeback() and clear folio X's TOWRITE tag. 0 4K 8K | |/////| (flag: DIRTY|WRITEBACK, tag: DIRTY)As a result, process B won't see folio X in its batch, and returns withoutwaiting for it. This breaks the WB_SYNC_ALL ordering requirement.Fix this by using btrfs_subpage_set_writeback_keepwrite(), which retainsthe TOWRITE tag. We now manually clear the tag only after the folio becomesclean, via the xas operation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: prevent softlockup in jbd2_log_do_checkpoint()Both jbd2_log_do_checkpoint() and jbd2_journal_shrink_checkpoint_list()periodically release j_list_lock after processing a batch of buffers toavoid long hold times on the j_list_lock. However, since both functionscontend for j_list_lock, the combined time spent waiting and processingcan be significant.jbd2_journal_shrink_checkpoint_list() explicitly calls cond_resched() whenneed_resched() is true to avoid softlockups during prolonged operations.But jbd2_log_do_checkpoint() only exits its loop when need_resched() istrue, relying on potentially sleeping functions like __flush_batch() orwait_on_buffer() to trigger rescheduling. If those functions do not sleep,the kernel may hit a softlockup.watchdog: BUG: soft lockup - CPU#3 stuck for 156s! [kworker/u129:2:373]CPU: 3 PID: 373 Comm: kworker/u129:2 Kdump: loaded Not tainted 6.6.0+ #10Hardware name: Huawei TaiShan 2280 /BC11SPCD, BIOS 1.27 06/13/2017Workqueue: writeback wb_workfn (flush-7:2)pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : native_queued_spin_lock_slowpath+0x358/0x418lr : jbd2_log_do_checkpoint+0x31c/0x438 [jbd2]Call trace: native_queued_spin_lock_slowpath+0x358/0x418 jbd2_log_do_checkpoint+0x31c/0x438 [jbd2] __jbd2_log_wait_for_space+0xfc/0x2f8 [jbd2] add_transaction_credits+0x3bc/0x418 [jbd2] start_this_handle+0xf8/0x560 [jbd2] jbd2__journal_start+0x118/0x228 [jbd2] __ext4_journal_start_sb+0x110/0x188 [ext4] ext4_do_writepages+0x3dc/0x740 [ext4] ext4_writepages+0xa4/0x190 [ext4] do_writepages+0x94/0x228 __writeback_single_inode+0x48/0x318 writeback_sb_inodes+0x204/0x590 __writeback_inodes_wb+0x54/0xf8 wb_writeback+0x2cc/0x3d8 wb_do_writeback+0x2e0/0x2f8 wb_workfn+0x80/0x2a8 process_one_work+0x178/0x3e8 worker_thread+0x234/0x3b8 kthread+0xf0/0x108 ret_from_fork+0x10/0x20So explicitly call cond_resched() in jbd2_log_do_checkpoint() to avoidsoftlockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: Fix configfs group list head handlingDoing a list_del() on the epf_group field of struct pci_epf_driver inpci_epf_remove_cfs() is not correct as this field is a list head, nota list entry. This list_del() call triggers a KASAN warning when anendpoint function driver which has a configfs attribute group is torndown:==================================================================BUG: KASAN: slab-use-after-free in pci_epf_remove_cfs+0x17c/0x198Write of size 8 at addr ffff00010f4a0d80 by task rmmod/319CPU: 3 UID: 0 PID: 319 Comm: rmmod Not tainted 6.16.0-rc2 #1 NONEHardware name: Radxa ROCK 5B (DT)Call trace:show_stack+0x2c/0x84 (C)dump_stack_lvl+0x70/0x98print_report+0x17c/0x538kasan_report+0xb8/0x190__asan_report_store8_noabort+0x20/0x2cpci_epf_remove_cfs+0x17c/0x198pci_epf_unregister_driver+0x18/0x30nvmet_pci_epf_cleanup_module+0x24/0x30 [nvmet_pci_epf]__arm64_sys_delete_module+0x264/0x424invoke_syscall+0x70/0x260el0_svc_common.constprop.0+0xac/0x230do_el0_svc+0x40/0x58el0_svc+0x48/0xdcel0t_64_sync_handler+0x10c/0x138el0t_64_sync+0x198/0x19c...Remove this incorrect list_del() call from pci_epf_remove_cfs().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39789 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: x86/aegis - Add missing error checksThe skcipher_walk functions can allocate memory and can fail, sochecking for errors is necessary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39794 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ARM: tegra: Use I/O memcpy to write to IRAMKasan crashes the kernel trying to check boundaries when using thenormal memcpy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39795 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block: avoid possible overflow for chunk_sectors check in blk_stack_limits()In blk_stack_limits(), we check that the t->chunk_sectors value is amultiple of the t->physical_block_size value.However, by finding the chunk_sectors value in bytes, we may overflowthe unsigned int which holds chunk_sectors, so change the check to bebased on sectors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39800 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: abort transaction on unexpected eb generation at btrfs_copy_root()If we find an unexpected generation for the extent buffer we are cloningat btrfs_copy_root(), we just WARN_ON() and don't error out and abort thetransaction, meaning we allow to persist metadata with an unexpectedgeneration. Instead of warning only, abort the transaction and return-EUCLEAN.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hid-ntrig: fix unable to handle page fault in ntrig_report_version()in ntrig_report_version(), hdev parameter passed from hid_probe().sending descriptor to /dev/uhid can make hdev->dev.parent->parent to nullif hdev->dev.parent->parent is null, usb_dev hasinvalid address(0xffffffffffffff58) that hid_to_usb_dev(hdev) returnedwhen usb_rcvctrlpipe() use usb_dev,it triggerpage fault error for address(0xffffffffffffff58)add null check logic to ntrig_report_version()before calling hid_to_usb_dev()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39810 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix memory corruption when FW resources change during ifdownbnxt_set_dflt_rings() assumes that it is always called before any TC hasbeen created. So it doesn't take bp->num_tc into account and assumesthat it is always 0 or 1.In the FW resource or capability change scenario, the FW will returnflags in bnxt_hwrm_if_change() that will cause the driver toreinitialize and call bnxt_cancel_reservations(). This will lead tobnxt_init_dflt_ring_mode() calling bnxt_set_dflt_rings() and bp->num_tcmay be greater than 1. This will cause bp->tx_ring[] to be sized toosmall and cause memory corruption in bnxt_alloc_cp_rings().Fix it by properly scaling the TX rings by bp->num_tc in the codepaths mentioned above. Add 2 helper functions to determinebp->tx_nr_rings and bp->tx_nr_rings_per_tc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix potential warning in trace_printk_seq during ftrace_dumpWhen calling ftrace_dump_one() concurrently with reading trace_pipe,a WARN_ON_ONCE() in trace_printk_seq() can be triggered due to a racecondition.The issue occurs because:CPU0 (ftrace_dump) CPU1 (reader)echo z > /proc/sysrq-trigger!trace_empty(&iter)trace_iterator_reset(&iter) <- len = size = 0 cat /sys/kernel/tracing/trace_pipetrace_find_next_entry_inc(&iter) __find_next_entry ring_buffer_empty_cpu <- all empty return NULLtrace_printk_seq(&iter.seq) WARN_ON_ONCE(s->seq.len >= s->seq.size)In the context between trace_empty() and trace_find_next_entry_inc()during ftrace_dump, the ring buffer data was consumed by other readers.This caused trace_find_next_entry_inc to return NULL, failing to populate`iter.seq`. At this point, due to the prior trace_iterator_reset, both`iter.seq.len` and `iter.seq.size` were set to 0. Since they are equal,the WARN_ON_ONCE condition is triggered.Move the trace_printk_seq() into the if block that checks to make sure thereturn value of trace_find_next_entry_inc() is non-NULL inftrace_dump_one(), ensuring the 'iter.seq' is properly populated beforesubsequent operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39817 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:efivarfs: Fix slab-out-of-bounds in efivarfs_d_compareObserved on kernel 6.6 (present on master as well): BUG: KASAN: slab-out-of-bounds in memcmp+0x98/0xd0 Call trace: kasan_check_range+0xe8/0x190 __asan_loadN+0x1c/0x28 memcmp+0x98/0xd0 efivarfs_d_compare+0x68/0xd8 __d_lookup_rcu_op_compare+0x178/0x218 __d_lookup_rcu+0x1f8/0x228 d_alloc_parallel+0x150/0x648 lookup_open.isra.0+0x5f0/0x8d0 open_last_lookups+0x264/0x828 path_openat+0x130/0x3f8 do_filp_open+0x114/0x248 do_sys_openat2+0x340/0x3c0 __arm64_sys_openat+0x120/0x1a0If dentry->d_name.len < EFI_VARIABLE_GUID_LEN , 'guid' can becomenegative, leadings to oob. The issue can be triggered by parallellookups using invalid filename: T1 T2 lookup_open ->lookup simple_lookup d_add // invalid dentry is added to hash list lookup_open d_alloc_parallel __d_lookup_rcu __d_lookup_rcu_op_compare hlist_bl_for_each_entry_rcu // invalid dentry can be retrieved ->d_compare efivarfs_d_compare // oobFix it by checking 'guid' before cmp.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/smb: Fix inconsistent refcnt updateA possible inconsistent update of refcount was identified in `smb2_compound_op`.Such inconsistent update could lead to possible resource leaks.Why it is a possible bug:1. In the comment section of the function, it clearly states that thereference to `cfile` should be dropped after calling this function.2. Every control flow path would check and drop the reference to`cfile`, except the patched one.3. Existing callers would not handle refcount update of `cfile` if-ENOMEM is returned.To fix the bug, an extra goto label "out" is added, to make sure that thecleanup logic would always be respected. As the problem is caused by theallocation failure of `vars`, the cleanup logic between label "finished"and "out" can be safely ignored. According to the definition of function`is_replayable_error`, the error code of "-ENOMEM" is not recoverable.Therefore, the replay logic also gets ignored.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().syzbot reported the splat below. [0]When atmtcp_v_open() or atmtcp_v_close() is called via connect()or close(), atmtcp_send_control() is called to send an in-kernelspecial message.The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length.Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.The notable thing is struct atmtcp_control is uAPI but has aspace for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;The special message is processed in atmtcp_recv_control() calledfrom atmtcp_c_send().atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()The problem is sendmsg() does not validate the message length anduserspace can abuse atmtcp_recv_control() to overwrite any kptrby atmtcp_control.Let's add a new ->pre_send() hook to validate messages from sendmsg().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTIKASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f]CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:atmtcp_recv_control drivers/atm/atmtcp.c:93 [inline]RIP: 0010:atmtcp_c_send+0x1da/0x950 drivers/atm/atmtcp.c:297Code: 4d 8d 75 1a 4c 89 f0 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 15 06 00 00 41 0f b7 1e 4d 8d b7 60 05 00 00 4c 89 f0 48 c1 e8 03 <42> 0f b6 04 20 84 c0 0f 85 13 06 00 00 66 41 89 1e 4d 8d 75 1c 4cRSP: 0018:ffffc90003f5f810 EFLAGS: 00010203RAX: 00000000200000ab RBX: 0000000000000000 RCX: 0000000000000000RDX: ffff88802a510000 RSI: 00000000ffffffff RDI: ffff888030a6068cRBP: ffff88802699fb40 R08: ffff888030a606eb R09: 1ffff1100614c0ddR10: dffffc0000000000 R11: ffffffff8718fc40 R12: dffffc0000000000R13: ffff888030a60680 R14: 000000010000055f R15: 00000000ffffffffFS: 00007f8d7e9236c0(0000) GS:ffff888125c1c000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000045ad50 CR3: 0000000075bde000 CR4: 00000000003526f0Call Trace: vcc_sendmsg+0xa10/0xc60 net/atm/common.c:645 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg+0x219/0x270 net/socket.c:729 ____sys_sendmsg+0x505/0x830 net/socket.c:2614 ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2668 __sys_sendmsg net/socket.c:2700 [inline] __do_sys_sendmsg net/socket.c:2705 [inline] __se_sys_sendmsg net/socket.c:2703 [inline] __x64_sys_sendmsg+0x19b/0x260 net/socket.c:2703 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f8d7e96a4a9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f8d7e923198 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f8d7e9f4308 RCX: 00007f8d7e96a4a9RDX: 0000000000000000 RSI: 0000200000000240 RDI: 0000000000000005RBP: 00007f8d7e9f4300 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f8d7e9c10acR13: 00007f8d7e9231a0 R14: 0000200000000200 R15: 0000200000000250 Modules linked in:

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39829 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:trace/fgraph: Fix the warning caused by missing unregister notifierThis warning was triggered during testing on v6.16:notifier callback ftrace_suspend_notifier_call already registeredWARNING: CPU: 2 PID: 86 at kernel/notifier.c:23 notifier_chain_register+0x44/0xb0...Call Trace: blocking_notifier_chain_register+0x34/0x60 register_ftrace_graph+0x330/0x410 ftrace_profile_write+0x1e9/0x340 vfs_write+0xf8/0x420 ? filp_flush+0x8a/0xa0 ? filp_close+0x1f/0x30 ? do_dup2+0xaf/0x160 ksys_write+0x65/0xe0 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x77/0x7fWhen writing to the function_profile_enabled interface, the notifier wasnot unregistered after start_graph_tracing failed, causing a warning thenext time function_profile_enabled was written.Fixed by adding unregister_pm_notifier in the exception path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39833 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mISDN: hfcpci: Fix warning when deleting uninitialized timerWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leadsto the following splat:[ 250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0[ 250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0[ 250.218775] Modules linked in: hfcpci(-) mISDN_core[ 250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)[ 250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0[ 250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d[ 250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286[ 250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95[ 250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0[ 250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39[ 250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001[ 250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8[ 250.232454] FS: 00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000[ 250.233851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0[ 250.236117] Call Trace:[ 250.236599] [ 250.236967] ? trace_irq_enable.constprop.0+0xd4/0x130[ 250.237920] debug_object_assert_init+0x1f6/0x310[ 250.238762] ? __pfx_debug_object_assert_init+0x10/0x10[ 250.239658] ? __lock_acquire+0xdea/0x1c70[ 250.240369] __try_to_del_timer_sync+0x69/0x140[ 250.241172] ? __pfx___try_to_del_timer_sync+0x10/0x10[ 250.242058] ? __timer_delete_sync+0xc6/0x120[ 250.242842] ? lock_acquire+0x30/0x80[ 250.243474] ? __timer_delete_sync+0xc6/0x120[ 250.244262] __timer_delete_sync+0x98/0x120[ 250.245015] HFC_cleanup+0x10/0x20 [hfcpci][ 250.245704] __do_sys_delete_module+0x348/0x510[ 250.246461] ? __pfx___do_sys_delete_module+0x10/0x10[ 250.247338] do_syscall_64+0xc1/0x360[ 250.247924] entry_SYSCALL_64_after_hwframe+0x77/0x7fFix this by initializing hfc_tl timer with DEFINE_TIMER macro.Also, use mod_timer instead of manual timeout update.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39835 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: do not propagate ENODATA disk errors into xattr codeENODATA (aka ENOATTR) has a very specific meaning in the xfs xattr code;namely, that the requested attribute name could not be found.However, a medium error from disk may also return ENODATA. At best,this medium error may escape to userspace as "attribute not found"when in fact it's an IO (disk) error.At worst, we may oops in xfs_attr_leaf_get() when we do: error = xfs_attr_leaf_hasname(args, &bp); if (error == -ENOATTR) { xfs_trans_brelse(args->trans, bp); return error; }because an ENODATA/ENOATTR error from disk leaves us with a null bp,and the xfs_trans_brelse will then null-deref it.As discussed on the list, we really need to modify the lower levelIO functions to trap all disk errors and ensure that we don't letunique errors like this leak up into higher xfs functions - manylike this should be remapped to EIO.However, this patch directly addresses a reported bug in the xattrcode, and should be safe to backport to stable kernels. A larger-scopepatch to handle more unique errors at lower levels can follow later.(Note, prior to 07120f1abdff we did not oops, but we did return thewrong error code to userspace.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: fix OOB read/write in network-coding decodebatadv_nc_skb_decode_packet() trusts coded_len and checks only againstskb->len. XOR starts at sizeof(struct batadv_unicast_packet), reducingpayload headroom, and the source skb length is not verified, allowing anout-of-bounds read and a small out-of-bounds write.Validate that coded_len fits within the payload area of both destinationand source sk_buffs before XORing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39841 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix buffer free/clear order in deferred receive pathFix a use-after-free window by correcting the buffer release sequence inthe deferred receive path. The code freed the RQ buffer first and onlythen cleared the context pointer under the lock. Concurrent paths (e.g.,ABTS and the repost path) also inspect and release the same pointer underthe lock, so the old order could lead to double-free/UAF.Note that the repost path already uses the correct pattern: detach thepointer under the lock, then free it after dropping the lock. Thedeferred path should do the same.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm: move page table sync declarations to linux/pgtable.hDuring our internal testing, we started observing intermittent bootfailures when the machine uses 4-level paging and has a large amount ofpersistent memory: BUG: unable to handle page fault for address: ffffe70000000034 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP NOPTI RIP: 0010:__init_single_page+0x9/0x6d Call Trace: __init_zone_device_page+0x17/0x5d memmap_init_zone_device+0x154/0x1bb pagemap_range+0x2e0/0x40f memremap_pages+0x10b/0x2f0 devm_memremap_pages+0x1e/0x60 dev_dax_probe+0xce/0x2ec [device_dax] dax_bus_probe+0x6d/0xc9 [... snip ...] It turns out that the kernel panics while initializing vmemmap (structpage array) when the vmemmap region spans two PGD entries, because the newPGD entry is only installed in init_mm.pgd, but not in the page tables ofother tasks.And looking at __populate_section_memmap(): if (vmemmap_can_optimize(altmap, pgmap)) // does not sync top level page tables r = vmemmap_populate_compound_pages(pfn, start, end, nid, pgmap); else // sync top level page tables in x86 r = vmemmap_populate(start, end, nid, altmap);In the normal path, vmemmap_populate() in arch/x86/mm/init_64.csynchronizes the top level page table (See commit 9b861528a801 ("x86-64,mem: Update all PGDs for direct mapping and vmemmap mapping changes")) sothat all tasks in the system can see the new vmemmap area.However, when vmemmap_can_optimize() returns true, the optimized pathskips synchronization of top-level page tables. This is becausevmemmap_populate_compound_pages() is implemented in core MM code, whichdoes not handle synchronization of the top-level page tables. Instead,the core MM has historically relied on each architecture to perform thissynchronization manually.We're not the first party to encounter a crash caused by not-sync'd toplevel page tables: earlier this year, Gwan-gyeong Mun attempted to addressthe issue [1] [2] after hitting a kernel panic when x86 code accessed thevmemmap area before the corresponding top-level entries were synced. Atthat time, the issue was believed to be triggered only when struct pagewas enlarged for debugging purposes, and the patch did not get furtherupdates.It turns out that current approach of relying on each arch to handle thepage table sync manually is fragile because 1) it's easy to forget to syncthe top level page table, and 2) it's also easy to overlook that thekernel should not access the vmemmap and direct mapping areas before thesync.# The solution: Make page table sync more code robust and harder to missTo address this, Dave Hansen suggested [3] [4] introducing{pgd,p4d}_populate_kernel() for updating kernel portion of the page tablesand allow each architecture to explicitly perform synchronization wheninstalling top-level entries. With this approach, we no longer need toworry about missing the sync step, reducing the risk of futureregressions.The new interface reuses existing ARCH_PAGE_TABLE_SYNC_MASK,PGTBL_P*D_MODIFIED and arch_sync_kernel_mappings() facility used byvmalloc and ioremap to synchronize page tables.pgd_populate_kernel() looks like this:static inline void pgd_populate_kernel(unsigned long addr, pgd_t *pgd, p4d_t *p4d){ pgd_populate(&init_mm, pgd, p4d); if (ARCH_PAGE_TABLE_SYNC_MASK & PGTBL_PGD_MODIFIED) arch_sync_kernel_mappings(addr, addr);}It is worth noting that vmalloc() and apply_to_range() carefullysynchronizes page tables by calling p*d_alloc_track() andarch_sync_kernel_mappings(), and thus they are not affected by---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ppp: fix memory leak in pad_compress_skbIf alloc_skb() fails in pad_compress_skb(), it returns NULL withoutreleasing the old skb. The caller does: skb = pad_compress_skb(ppp, skb); if (!skb) goto drop;drop: kfree_skb(skb);When pad_compress_skb() returns NULL, the reference to the old skb islost and kfree_skb(skb) ends up doing nothing, leading to a memory leak.Align pad_compress_skb() semantics with realloc(): only free the oldskb if allocation and compression succeed. At the call site, use thenew_skb variable so the original skb is not lost when pad_compress_skb()fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39850 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objectsWhen the "proxy" option is enabled on a VXLAN device, the device willsuppress ARP requests and IPv6 Neighbor Solicitation messages if it isable to reply on behalf of the remote host. That is, if a matching andvalid neighbor entry is configured on the VXLAN device whose MAC addressis not behind the "any" remote (0.0.0.0 / ::).The code currently assumes that the FDB entry for the neighbor's MACaddress points to a valid remote destination, but this is incorrect ifthe entry is associated with an FDB nexthop group. This can result in aNPD [1][3] which can be reproduced using [2][4].Fix by checking that the remote destination exists before dereferencingit.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_xmit+0xb58/0x15f0[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip nexthop add id 1 via 192.0.2.2 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3[3]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014RIP: 0010:vxlan_xmit+0x803/0x1600[...]Call Trace: dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 ip6_finish_output2+0x210/0x6c0 ip6_finish_output+0x1af/0x2b0 ip6_mr_output+0x92/0x3e0 ip6_send_skb+0x30/0x90 rawv6_sendmsg+0xe6e/0x12e0 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7f383422ec77[4] #!/bin/bash ip address add 2001:db8:1::1/128 dev lo ip nexthop add id 1 via 2001:db8:1::1 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0 bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10 ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Fix NPD when refreshing an FDB entry with a nexthop objectVXLAN FDB entries can point to either a remote destination or an FDBnexthop group. The latter is usually used in EVPN deployments wherelearning is disabled.However, when learning is enabled, an incoming packet might try torefresh an FDB entry that points to an FDB nexthop group and thereforedoes not have a remote. Such packets should be dropped, but they areonly dropped after dereferencing the non-existent remote, resulting in aNPD [1] which can be reproduced using [2].Fix by dropping such packets earlier. Remove the misleading comment fromfirst_remote_rcu().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]CPU: 13 UID: 0 PID: 361 Comm: mausezahn Not tainted 6.17.0-rc1-virtme-g9f6b606b6b37 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:vxlan_snoop+0x98/0x1e0[...]Call Trace: vxlan_encap_bypass+0x209/0x240 encap_bypass_if_local+0xb1/0x100 vxlan_xmit_one+0x1375/0x17e0 vxlan_xmit+0x6b4/0x15f0 dev_hard_start_xmit+0x5d/0x1c0 __dev_queue_xmit+0x246/0xfd0 packet_sendmsg+0x113a/0x1850 __sock_sendmsg+0x38/0x70 __sys_sendto+0x126/0x180 __x64_sys_sendto+0x24/0x30 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2] #!/bin/bash ip address add 192.0.2.1/32 dev lo ip address add 192.0.2.2/32 dev lo ip nexthop add id 1 via 192.0.2.3 fdb ip nexthop add id 10 group 1 fdb ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 12345 localbypass ip link add name vx1 up type vxlan id 10020 local 192.0.2.2 dstport 54321 learning bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 192.0.2.2 port 54321 vni 10020 bridge fdb add 00:aa:bb:cc:dd:ee dev vx1 self static nhid 10 mausezahn vx0 -a 00:aa:bb:cc:dd:ee -b 00:11:22:33:44:55 -c 1 -q

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39853 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: Fix potential invalid access when MAC list is emptylist_first_entry() never returns NULL - if the list is empty, it stillreturns a pointer to an invalid object, leading to potential invalidmemory access when dereferenced.Fix this by using list_first_entry_or_null instead of list_first_entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39859 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: ocp: fix use-after-free bugs causing by ptp_ocp_watchdogThe ptp_ocp_detach() only shuts down the watchdog timer if it ispending. However, if the timer handler is already running, thetimer_delete_sync() is not called. This leads to race conditionswhere the devlink that contains the ptp_ocp is deallocated whilethe timer handler is still accessing it, resulting in use-after-freebugs. The following details one of the race scenarios.(thread 1) | (thread 2)ptp_ocp_remove() | ptp_ocp_detach() | ptp_ocp_watchdog() if (timer_pending(&bp->watchdog))| bp = timer_container_of() timer_delete_sync() | | devlink_free(devlink) //free | | bp-> //useResolve this by unconditionally calling timer_delete_sync() to ensurethe timer is reliably deactivated, preventing any access after free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39863 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix use-after-free when rescheduling brcmf_btcoex_info workThe brcmf_btcoex_detach() only shuts down the btcoex timer, if theflag timer_on is false. However, the brcmf_btcoex_timerfunc(), whichruns as timer handler, sets timer_on to false. This creates criticalrace conditions:1.If brcmf_btcoex_detach() is called while brcmf_btcoex_timerfunc()is executing, it may observe timer_on as false and skip the call totimer_shutdown_sync().2.The brcmf_btcoex_timerfunc() may then reschedule the brcmf_btcoex_infoworker after the cancel_work_sync() has been executed, resulting inuse-after-free bugs.The use-after-free bugs occur in two distinct scenarios, depending onthe timing of when the brcmf_btcoex_info struct is freed relative tothe execution of its worker thread.Scenario 1: Freed before the worker is scheduledThe brcmf_btcoex_info is deallocated before the worker is scheduled.A race condition can occur when schedule_work(&bt_local->work) iscalled after the target memory has been freed. The sequence of eventsis detailed below:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | kfree(cfg->btcoex); // FREE | | schedule_work(&bt_local->work); // USEScenario 2: Freed after the worker is scheduledThe brcmf_btcoex_info is freed after the worker has been scheduledbut before or during its execution. In this case, statements withinthe brcmf_btcoex_handler() - such as the container_of macro andsubsequent dereferences of the brcmf_btcoex_info object will causea use-after-free access. The following timeline illustrates thisscenario:CPU0 | CPU1brcmf_btcoex_detach | brcmf_btcoex_timerfunc | bt_local->timer_on = false; if (cfg->btcoex->timer_on) | ... | cancel_work_sync(); | ... | schedule_work(); // Reschedule | kfree(cfg->btcoex); // FREE | brcmf_btcoex_handler() // Worker /* | btci = container_of(....); // USE The kfree() above could | ... also occur at any point | btci-> // USE during the worker's execution| */ |To resolve the race conditions, drop the conditional check and calltimer_shutdown_sync() directly. It can deactivate the timer reliably,regardless of its current state. Once stopped, the timer_on state isthen set to false.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39864 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: fix use-after-free in cmp_bss()Following bss_free() quirk introduced in commit 776b3580178f("cfg80211: track hidden SSID networks properly"), adjustcfg80211_update_known_bss() to free the last beacon frameelements only if they're not shared via the corresponding'hidden_beacon_bss' pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39865 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: fix NULL pointer dereference in tee_shm_puttee_shm_put have NULL pointer dereference:__optee_disable_shm_cache --> shm = reg_pair_to_ptr(...);//shm maybe return NULL tee_shm_free(shm); --> tee_shm_put(shm);//crashAdd check in tee_shm_put to fix it.panic log:Unable to handle kernel paging request at virtual address 0000000000100ccaMem abort info:ESR = 0x0000000096000004EC = 0x25: DABT (current EL), IL = 32 bitsSET = 0, FnV = 0EA = 0, S1PTW = 0FSC = 0x04: level 0 translation faultData abort info:ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000CM = 0, WnR = 0, TnD = 0, TagAccess = 0GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=0000002049d07000[0000000000100cca] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] SMPCPU: 2 PID: 14442 Comm: systemd-sleep Tainted: P OE ------- ----6.6.0-39-generic #38Source Version: 938b255f6cb8817c95b0dd5c8c2944acfce94b07Hardware name: greatwall GW-001Y1A-FTH, BIOS Great Wall BIOS V3.010/26/2022pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : tee_shm_put+0x24/0x188lr : tee_shm_free+0x14/0x28sp : ffff001f98f9faf0x29: ffff001f98f9faf0 x28: ffff0020df543cc0 x27: 0000000000000000x26: ffff001f811344a0 x25: ffff8000818dac00 x24: ffff800082d8d048x23: ffff001f850fcd18 x22: 0000000000000001 x21: ffff001f98f9fb88x20: ffff001f83e76218 x19: ffff001f83e761e0 x18: 000000000000ffffx17: 303a30303a303030 x16: 0000000000000000 x15: 0000000000000003x14: 0000000000000001 x13: 0000000000000000 x12: 0101010101010101x11: 0000000000000001 x10: 0000000000000001 x9 : ffff800080e08d0cx8 : ffff001f98f9fb88 x7 : 0000000000000000 x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000x2 : ffff001f83e761e0 x1 : 00000000ffff001f x0 : 0000000000100ccaCall trace:tee_shm_put+0x24/0x188tee_shm_free+0x14/0x28__optee_disable_shm_cache+0xa8/0x108optee_shutdown+0x28/0x38platform_shutdown+0x28/0x40device_shutdown+0x144/0x2b0kernel_power_off+0x3c/0x80hibernate+0x35c/0x388state_store+0x64/0x80kobj_attr_store+0x14/0x28sysfs_kf_write+0x48/0x60kernfs_fop_write_iter+0x128/0x1c0vfs_write+0x270/0x370ksys_write+0x6c/0x100__arm64_sys_write+0x20/0x30invoke_syscall+0x4c/0x120el0_svc_common.constprop.0+0x44/0xf0do_el0_svc+0x24/0x38el0_svc+0x24/0x88el0t_64_sync_handler+0x134/0x150el0t_64_sync+0x14c/0x15

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39873 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: xilinx_can: xcan_write_frame(): fix use-after-free of transmitted SKBcan_put_echo_skb() takes ownership of the SKB and it may be freedduring or after the call.However, xilinx_can xcan_write_frame() keeps using SKB after the call.Fix that by only calling can_put_echo_skb() after the code is donetouching the SKB.The tx_lock is held for the entire xcan_write_frame() execution andalso on the can_get_echo_skb() side so the order of operations does notmatter.An earlier fix commit 3d3c817c3a40 ("can: xilinx_can: Fix usage of skbmemory") did not move the can_put_echo_skb() call far enough.[mkl: add "commit" in front of sha1 in patch description][mkl: fix indention]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39876 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: Fix possible NPD in fec_enet_phy_reset_after_clk_enable()The function of_phy_find_device may return NULL, so we need to takecare before dereferencing phy_dev.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39880 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:libceph: fix invalid accesses to ceph_connection_v1_infoThere is a place where generic code in messenger.c is reading andanother place where it is writing to con->v1 union member withoutchecking that the union member is active (i.e. msgr1 is in use).On 64-bit systems, con->v1.auth_retry overlaps with con->v2.out_iter,so such a read is almost guaranteed to return a bogus value instead of0 when msgr2 is in use. This ends up being fairly benign because theside effect is just the invalidation of the authorizer and successivefetching of new tickets.con->v1.connect_seq overlaps with con->v2.conn_bufs and the fact thatit's being written to can cause more serious consequences, but luckilyit's not something that happens often.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39883 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memoryWhen I did memory failure tests, below panic occurs:page dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))kernel BUG at include/linux/page-flags.h:616!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Call Trace: unpoison_memory+0x2f3/0x590 simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110 debugfs_attr_write+0x42/0x60 full_proxy_write+0x5b/0x80 vfs_write+0xd5/0x540 ksys_write+0x64/0xe0 do_syscall_64+0xb9/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f08f0314887RSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887RDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001RBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffffR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009R13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00 Modules linked in: hwpoison_inject---[ end trace 0000000000000000 ]---RIP: 0010:unpoison_memory+0x2f3/0x590RSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246RAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8RDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0RBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffbR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000R13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffeFS: 00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0Kernel panic - not syncing: Fatal exceptionKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)---[ end Kernel panic - not syncing: Fatal exception ]---The root cause is that unpoison_memory() tries to check the PG_HWPoisonflags of an uninitialized page. So VM_BUG_ON_PAGE(PagePoisoned(page)) istriggered. This can be reproduced by below steps:1.Offline memory block: echo offline > /sys/devices/system/memory/memory12/state2.Get offlined memory pfn: page-types -b n -rlN3.Write pfn to unpoison-pfn echo > /sys/kernel/debug/hwpoison/unpoison-pfnThis scenario can be identified by pfn_to_online_page() returning NULL. And ZONE_DEVICE pages are never expected, so we can simply fail ifpfn_to_online_page() == NULL to fix the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39885 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix recursive semaphore deadlock in fiemap callsyzbot detected a OCFS2 hang due to a recursive semaphore on aFS_IOC_FIEMAP of the extent list on a specially crafted mmap file.context_switch kernel/sched/core.c:5357 [inline] __schedule+0x1798/0x4cc0 kernel/sched/core.c:6961 __schedule_loop kernel/sched/core.c:7043 [inline] schedule+0x165/0x360 kernel/sched/core.c:7058 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7115 rwsem_down_write_slowpath+0x872/0xfe0 kernel/locking/rwsem.c:1185 __down_write_common kernel/locking/rwsem.c:1317 [inline] __down_write kernel/locking/rwsem.c:1326 [inline] down_write+0x1ab/0x1f0 kernel/locking/rwsem.c:1591 ocfs2_page_mkwrite+0x2ff/0xc40 fs/ocfs2/mmap.c:142 do_page_mkwrite+0x14d/0x310 mm/memory.c:3361 wp_page_shared mm/memory.c:3762 [inline] do_wp_page+0x268d/0x5800 mm/memory.c:3981 handle_pte_fault mm/memory.c:6068 [inline] __handle_mm_fault+0x1033/0x5440 mm/memory.c:6195 handle_mm_fault+0x40a/0x8e0 mm/memory.c:6364 do_user_addr_fault+0x764/0x1390 arch/x86/mm/fault.c:1387 handle_page_fault arch/x86/mm/fault.c:1476 [inline] exc_page_fault+0x76/0xf0 arch/x86/mm/fault.c:1532 asm_exc_page_fault+0x26/0x30 arch/x86/include/asm/idtentry.h:623RIP: 0010:copy_user_generic arch/x86/include/asm/uaccess_64.h:126 [inline]RIP: 0010:raw_copy_to_user arch/x86/include/asm/uaccess_64.h:147 [inline]RIP: 0010:_inline_copy_to_user include/linux/uaccess.h:197 [inline]RIP: 0010:_copy_to_user+0x85/0xb0 lib/usercopy.c:26Code: e8 00 bc f7 fc 4d 39 fc 72 3d 4d 39 ec 77 38 e8 91 b9 f7 fc 4c 89f7 89 de e8 47 25 5b fd 0f 01 cb 4c 89 ff 48 89 d9 4c 89 f6 a4 0f1f 00 48 89 cb 0f 01 ca 48 89 d8 5b 41 5c 41 5d 41 5e 41RSP: 0018:ffffc9000403f950 EFLAGS: 00050256RAX: ffffffff84c7f101 RBX: 0000000000000038 RCX: 0000000000000038RDX: 0000000000000000 RSI: ffffc9000403f9e0 RDI: 0000200000000060RBP: ffffc9000403fa90 R08: ffffc9000403fa17 R09: 1ffff92000807f42R10: dffffc0000000000 R11: fffff52000807f43 R12: 0000200000000098R13: 00007ffffffff000 R14: ffffc9000403f9e0 R15: 0000200000000060 copy_to_user include/linux/uaccess.h:225 [inline] fiemap_fill_next_extent+0x1c0/0x390 fs/ioctl.c:145 ocfs2_fiemap+0x888/0xc90 fs/ocfs2/extent_map.c:806 ioctl_fiemap fs/ioctl.c:220 [inline] do_vfs_ioctl+0x1173/0x1430 fs/ioctl.c:532 __do_sys_ioctl fs/ioctl.c:596 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:584 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f5f13850fd9RSP: 002b:00007ffe3b3518b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 0000200000000000 RCX: 00007f5f13850fd9RDX: 0000200000000040 RSI: 00000000c020660b RDI: 0000000000000004RBP: 6165627472616568 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe3b3518f0R13: 00007ffe3b351b18 R14: 431bde82d7b634db R15: 00007f5f1389a03bocfs2_fiemap() takes a read lock of the ip_alloc_sem semaphore (sincev2.6.22-527-g7307de80510a) and calls fiemap_fill_next_extent() to read theextent list of this running mmap executable. The user supplied buffer tohold the fiemap information page faults calling ocfs2_page_mkwrite() whichwill take a write lock (since v2.6.27-38-g00dc417fa3e7) of the samesemaphore. This recursive semaphore will hold filesystem locks and causesa hang of the fileystem.The ip_alloc_sem protects the inode extent list and size. Release theread semphore before calling fiemap_fill_next_extent() in ocfs2_fiemap()and ocfs2_fiemap_inline(). This does an unnecessary semaphore lock/unlockon the last extent but simplifies the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39902 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/slub: avoid accessing metadata when pointer is invalid in object_err()object_err() reports details of an object for further debugging, such asthe freelist pointer, redzone, etc. However, if the pointer is invalid,attempting to access object metadata can lead to a crash since it doesnot point to a valid object.One known path to the crash is when alloc_consistency_checks()determines the pointer to the allocated object is invalid because of afreelist corruption, and calls object_err() to report it. The debug codeshould report and handle the corruption gracefully and not crash in theprocess.In case the pointer is NULL or check_valid_pointer() returns false forthe pointer, only print the pointer value and skip accessing metadata.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39911 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: fix IRQ freeing in i40e_vsi_request_irq_msix error pathIf request_irq() in i40e_vsi_request_irq_msix() fails in an iterationlater than the first, the error path wants to free the IRQs requestedso far. However, it uses the wrong dev_id argument for free_irq(), soit does not free the IRQs correctly and instead triggers the warning: Trying to free already-free IRQ 173 WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0 Modules linked in: i40e(+) [...] CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy) Hardware name: [...] RIP: 0010:__free_irq+0x192/0x2c0 [...] Call Trace: free_irq+0x32/0x70 i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e] i40e_vsi_request_irq+0x79/0x80 [i40e] i40e_vsi_open+0x21f/0x2f0 [i40e] i40e_open+0x63/0x130 [i40e] __dev_open+0xfc/0x210 __dev_change_flags+0x1fc/0x240 netif_change_flags+0x27/0x70 do_setlink.isra.0+0x341/0xc70 rtnl_newlink+0x468/0x860 rtnetlink_rcv_msg+0x375/0x450 netlink_rcv_skb+0x5c/0x110 netlink_unicast+0x288/0x3c0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x3a2/0x3d0 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x82/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---Use the same dev_id for free_irq() as for request_irq().I tested this with inserting code to fail intentionally.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39913 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_bpf: Call sk_msg_free() when tcp_bpf_send_verdict() fails to allocate psock->cork.syzbot reported the splat below. [0]The repro does the following: 1. Load a sk_msg prog that calls bpf_msg_cork_bytes(msg, cork_bytes) 2. Attach the prog to a SOCKMAP 3. Add a socket to the SOCKMAP 4. Activate fault injection 5. Send data less than cork_bytesAt 5., the data is carried over to the next sendmsg() as it issmaller than the cork_bytes specified by bpf_msg_cork_bytes().Then, tcp_bpf_send_verdict() tries to allocate psock->cork to holdthe data, but this fails silently due to fault injection + __GFP_NOWARN.If the allocation fails, we need to revert the sk->sk_forward_allocchange done by sk_msg_alloc().Let's call sk_msg_free() when tcp_bpf_send_verdict fails to allocatepsock->cork.The "*copied" also needs to be updated such that a proper error canbe returned to the caller, sendmsg. It fails to allocate psock->cork.Nothing has been corked so far, so this patch simply sets "*copied"to 0.[0]:WARNING: net/ipv4/af_inet.c:156 at inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156, CPU#1: syz-executor/5983Modules linked in:CPU: 1 UID: 0 PID: 5983 Comm: syz-executor Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025RIP: 0010:inet_sock_destruct+0x623/0x730 net/ipv4/af_inet.c:156Code: 0f 0b 90 e9 62 fe ff ff e8 7a db b5 f7 90 0f 0b 90 e9 95 fe ff ff e8 6c db b5 f7 90 0f 0b 90 e9 bb fe ff ff e8 5e db b5 f7 90 <0f> 0b 90 e9 e1 fe ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 9f fcRSP: 0018:ffffc90000a08b48 EFLAGS: 00010246RAX: ffffffff8a09d0b2 RBX: dffffc0000000000 RCX: ffff888024a23c80RDX: 0000000000000100 RSI: 0000000000000fff RDI: 0000000000000000RBP: 0000000000000fff R08: ffff88807e07c627 R09: 1ffff1100fc0f8c4R10: dffffc0000000000 R11: ffffed100fc0f8c5 R12: ffff88807e07c380R13: dffffc0000000000 R14: ffff88807e07c60c R15: 1ffff1100fc0f872FS: 00005555604c4500(0000) GS:ffff888125af1000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005555604df5c8 CR3: 0000000032b06000 CR4: 00000000003526f0Call Trace: __sk_destruct+0x86/0x660 net/core/sock.c:2339 rcu_do_batch kernel/rcu/tree.c:2605 [inline] rcu_core+0xca8/0x1770 kernel/rcu/tree.c:2861 handle_softirqs+0x286/0x870 kernel/softirq.c:579 __do_softirq kernel/softirq.c:613 [inline] invoke_softirq kernel/softirq.c:453 [inline] __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680 irq_exit_rcu+0x9/0x30 kernel/softirq.c:696 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1052 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1052

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39925 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: j1939: implement NETDEV_UNREGISTER notification handlersyzbot is reporting unregister_netdevice: waiting for vcan0 to become free. Usage count = 2problem, for j1939 protocol did not have NETDEV_UNREGISTER notificationhandler for undoing changes made by j1939_sk_bind().Commit 25fe97cb7620 ("can: j1939: move j1939_priv_put() into sk_destructcallback") expects that a call to j1939_priv_put() can be unconditionallydelayed until j1939_sk_sock_destruct() is called. But we need to callj1939_priv_put() against an extra ref held by j1939_sk_bind() call(as a part of undoing changes made by j1939_sk_bind()) as soon asNETDEV_UNREGISTER notification fires (i.e. before j1939_sk_sock_destruct()is called via j1939_sk_release()). Otherwise, the extra ref on "structj1939_priv" held by j1939_sk_bind() call prevents "struct net_device" fromdropping the usage count to 1; making it impossible forunregister_netdevice() to continue.[mkl: remove space in front of label]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39931 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Set merge to zero early in af_alg_sendmsgIf an error causes af_alg_sendmsg to abort, ctx->merge may containa garbage value from the previous loop. This may then trigger acrash on the next entry into af_alg_sendmsg when it attempts to doa merge that can't be done.Fix this by setting ctx->merge to zero near the start of the loop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39937 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: rfkill: gpio: Fix crash due to dereferencering uninitialized pointerSince commit 7d5e9737efda ("net: rfkill: gpio: get the name and type fromdevice property") rfkill_find_type() gets called with the possiblyuninitialized "const char *type_name;" local variable.On x86 systems when rfkill-gpio binds to a "BCM4752" or "LNV4752"acpi_device, the rfkill->type is set based on the ACPI acpi_device_id: rfkill->type = (unsigned)id->driver_data;and there is no "type" property so device_property_read_string() will failand leave type_name uninitialized, leading to a potential crash.rfkill_find_type() does accept a NULL pointer, fix the potential crashby initializing type_name to NULL.Note likely sofar this has not been caught because:1. Not many x86 machines actually have a "BCM4752"/"LNV4752" acpi_device2. The stack happened to contain NULL where type_name is stored

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39944 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp()The original code relies on cancel_delayed_work() in otx2_ptp_destroy(),which does not ensure that the delayed work item synctstamp_work has fullycompleted if it was already running. This leads to use-after-free scenarioswhere otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_workremains active and attempts to dereference otx2_ptp in otx2_sync_tstamp().Furthermore, the synctstamp_work is cyclic, the likelihood of triggeringthe bug is nonnegligible.A typical race condition is illustrated below:CPU 0 (cleanup) | CPU 1 (delayed work callback)otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAFThis is confirmed by a KASAN report:BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0Write of size 8 at addr ffff88800aa09a18 by task bash/136...Call Trace: dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f...Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensurethat the delayed work item is properly canceled before the otx2_ptp isdeallocated.This bug was initially identified through static analysis. To reproduceand test it, I simulated the OcteonTX2 PCI device in QEMU and introducedartificial delays within the otx2_sync_tstamp() function to increase thelikelihood of triggering the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39989 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: use is_copy_from_user() to determine copy-from-user contextPatch series "mm/hwpoison: Fix regressions in memory failure handling",v4.## 1. What am I trying to do:This patchset resolves two critical regressions related to memory failurehandling that have appeared in the upstream kernel since version 5.17, ascompared to 5.10 LTS. - copyin case: poison found in user page while kernel copying from user space - instr case: poison found while instruction fetching in user space## 2. What is the expected outcome and why- For copyin case:Kernel can recover from poison found where kernel is doing get_user() orcopy_from_user() if those places get an error return and the kernel return-EFAULT to the process instead of crashing. More specifily, MCE handlerchecks the fixup handler type to decide whether an in kernel #MC can berecovered. When EX_TYPE_UACCESS is found, the PC jumps to recovery codespecified in _ASM_EXTABLE_FAULT() and return a -EFAULT to user space.- For instr case:If a poison found while instruction fetching in user space, full recoveryis possible. User process takes #PF, Linux allocates a new page and fillsby reading from storage.## 3. What actually happens and why- For copyin case: kernel panic since v5.17Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a newextable fixup type, EX_TYPE_EFAULT_REG, and later patches updated theextable fixup type for copy-from-user operations, changing it fromEX_TYPE_UACCESS to EX_TYPE_EFAULT_REG. It breaks previous EX_TYPE_UACCESShandling when posion found in get_user() or copy_from_user().- For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE raceWhen an uncorrected memory error is consumed there is a race between theCMCI from the memory controller reporting an uncorrected error with a UCNAsignature, and the core reporting and SRAR signature machine check whenthe data is about to be consumed.### Background: why *UN*corrected errors tied to *C*MCI in Intel platform [1]Prior to Icelake memory controllers reported patrol scrub events thatdetected a previously unseen uncorrected error in memory by signaling abroadcast machine check with an SRAO (Software Recoverable ActionOptional) signature in the machine check bank. This was overkill becauseit's not an urgent problem that no core is on the verge of consuming thatbad data. It's also found that multi SRAO UCE may cause nested MCEinterrupts and finally become an IERR.Hence, Intel downgrades the machine check bank signature of patrol scrubfrom SRAO to UCNA (Uncorrected, No Action required), and signal changed to#CMCI. Just to add to the confusion, Linux does take an action (inuc_decode_notifier()) to try to offline the page despite the UC*NA*signature name.### Background: why #CMCI and #MCE race when poison is consuming in Intel platform [1]Having decided that CMCI/UCNA is the best action for patrol scrub errors,the memory controller uses it for reads too. But the memory controller isexecuting asynchronously from the core, and can't tell the differencebetween a "real" read and a speculative read. So it will do CMCI/UCNA ifan error is found in any read.Thus:1) Core is clever and thinks address A is needed soon, issues a speculative read.2) Core finds it is going to use address A soon after sending the read request3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.Quite often (because speculation has got better) the CMCI from the memorycontroller is delivered before the core is committed to the instructionreading address A, so the interrupt is taken, and Linux offlines the page(marking it as poison).## Why user process is killed for instr caseCommit 046545a661af ("mm/hwpoison: fix error page recovered but reported"not---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39990 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check the helper function is valid in get_helper_protokernel test robot reported verifier bug [1] where the helper funcpointer could be NULL due to disabled config option.As Alexei suggested we could check on that in get_helper_protodirectly. Marking tail_call helper func with BPF_PTR_POISON,because it is unused by design. [1] https://lore.kernel.org/oe-lkp/202507160818.68358831-lkp@intel.com

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40010 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:afs: Fix potential null pointer dereference in afs_put_serverafs_put_server() accessed server->debug_id before the NULL check, whichcould lead to a null pointer dereference. Move the debug_id assignment,ensuring we never dereference a NULL server pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40011 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix null dereference in hdmi teardownpci_set_drvdata sets the value of pdev->driver_data to NULL,after which the driver_data obtained from the same dev isdereferenced in oaktrail_hdmi_i2c_exit, and the i2c_dev isextracted from it. To prevent this, swap these calls.Found by Linux Verification Center (linuxtesting.org) with Svacer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40029 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bus: fsl-mc: Check return value of platform_get_resource()platform_get_resource() returns NULL in case of failure, so check itsreturn value and propagate the error in order to prevent NULL pointerdereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40030 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: check the return value of pinmux_ops::get_function_name()While the API contract in docs doesn't specify it explicitly, thegeneric implementation of the get_function_name() callback from structpinmux_ops - pinmux_generic_get_function_name() - can fail and returnNULL. This is already checked in pinmux_check_ops() so add a similarcheck in pinmux_func_name_to_selector() instead of passing the returnedpointer right down to strcmp() where the NULL can get dereferenced. Thisis normal operation when adding new pinfunctions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: uinput - zero-initialize uinput_ff_upload_compat to avoid info leakStruct ff_effect_compat is embedded twice insideuinput_ff_upload_compat, contains internal padding. In particular, thereis a hole after struct ff_replay to satisfy alignment requirements forthe following union member. Without clearing the structure,copy_to_user() may leak stack data to userspace.Initialize ff_up_compat to zero before filling valid fields.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40040 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/ksm: fix flag-dropping behavior in ksm_madvisesyzkaller discovered the following crash: (kernel BUG)[ 44.607039] ------------[ cut here ]------------[ 44.607422] kernel BUG at mm/userfaultfd.c:2067![ 44.608148] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI[ 44.608814] CPU: 1 UID: 0 PID: 2475 Comm: reproducer Not tainted 6.16.0-rc6 #1 PREEMPT(none)[ 44.609635] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014[ 44.610695] RIP: 0010:userfaultfd_release_all+0x3a8/0x460[ 44.617726] Call Trace:[ 44.617926] [ 44.619284] userfaultfd_release+0xef/0x1b0[ 44.620976] __fput+0x3f9/0xb60[ 44.621240] fput_close_sync+0x110/0x210[ 44.622222] __x64_sys_close+0x8f/0x120[ 44.622530] do_syscall_64+0x5b/0x2f0[ 44.622840] entry_SYSCALL_64_after_hwframe+0x76/0x7e[ 44.623244] RIP: 0033:0x7f365bb3f227Kernel panics because it detects UFFD inconsistency duringuserfaultfd_release_all(). Specifically, a VMA which has a valid pointerto vma->vm_userfaultfd_ctx, but no UFFD flags in vma->vm_flags.The inconsistency is caused in ksm_madvise(): when user calls madvise()with MADV_UNMEARGEABLE on a VMA that is registered for UFFD in MINOR mode,it accidentally clears all flags stored in the upper 32 bits ofvma->vm_flags.Assuming x86_64 kernel build, unsigned long is 64-bit and unsigned int andint are 32-bit wide. This setup causes the following mishap during the &=~VM_MERGEABLE assignment.VM_MERGEABLE is a 32-bit constant of type unsigned int, 0x8000'0000. After ~ is applied, it becomes 0x7fff'ffff unsigned int, which is thenpromoted to unsigned long before the & operation. This promotion fillsupper 32 bits with leading 0s, as we're doing unsigned conversion (andeven for a signed conversion, this wouldn't help as the leading bit is 0).& operation thus ends up AND-ing vm_flags with 0x0000'0000'7fff'ffffinstead of intended 0xffff'ffff'7fff'ffff and hence accidentally clearsthe upper 32-bits of its value.Fix it by changing `VM_MERGEABLE` constant to unsigned long, using theBIT() macro.Note: other VM_* flags are not affected: This only happens to theVM_MERGEABLE flag, as the other VM_* flags are all constants of type intand after ~ operation, they end up with leading 1 and are thus convertedto unsigned long with leading 1s.Note 2:After commit 31defc3b01d9 ("userfaultfd: remove (VM_)BUG_ON()s"), this isno longer a kernel BUG, but a WARNING at the same place:[ 45.595973] WARNING: CPU: 1 PID: 2474 at mm/userfaultfd.c:2067but the root-cause (flag-drop) remains the same.[akpm@linux-foundation.org: rust bindgen wasn't able to handle BIT(), from Miguel]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40042 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix race condition in kprobe initialization causing NULL pointer dereferenceThere is a critical race condition in kprobe initialization that can lead toNULL pointer dereference and kernel crash.[1135630.084782] Unable to handle kernel paging request at virtual address 0000710a04630000...[1135630.260314] pstate: 404003c9 (nZcv DAIF +PAN -UAO)[1135630.269239] pc : kprobe_perf_func+0x30/0x260[1135630.277643] lr : kprobe_dispatcher+0x44/0x60[1135630.286041] sp : ffffaeff4977fa40[1135630.293441] x29: ffffaeff4977fa40 x28: ffffaf015340e400[1135630.302837] x27: 0000000000000000 x26: 0000000000000000[1135630.312257] x25: ffffaf029ed108a8 x24: ffffaf015340e528[1135630.321705] x23: ffffaeff4977fc50 x22: ffffaeff4977fc50[1135630.331154] x21: 0000000000000000 x20: ffffaeff4977fc50[1135630.340586] x19: ffffaf015340e400 x18: 0000000000000000[1135630.349985] x17: 0000000000000000 x16: 0000000000000000[1135630.359285] x15: 0000000000000000 x14: 0000000000000000[1135630.368445] x13: 0000000000000000 x12: 0000000000000000[1135630.377473] x11: 0000000000000000 x10: 0000000000000000[1135630.386411] x9 : 0000000000000000 x8 : 0000000000000000[1135630.395252] x7 : 0000000000000000 x6 : 0000000000000000[1135630.403963] x5 : 0000000000000000 x4 : 0000000000000000[1135630.412545] x3 : 0000710a04630000 x2 : 0000000000000006[1135630.421021] x1 : ffffaeff4977fc50 x0 : 0000710a04630000[1135630.429410] Call trace:[1135630.434828] kprobe_perf_func+0x30/0x260[1135630.441661] kprobe_dispatcher+0x44/0x60[1135630.448396] aggr_pre_handler+0x70/0xc8[1135630.454959] kprobe_breakpoint_handler+0x140/0x1e0[1135630.462435] brk_handler+0xbc/0xd8[1135630.468437] do_debug_exception+0x84/0x138[1135630.475074] el1_dbg+0x18/0x8c[1135630.480582] security_file_permission+0x0/0xd0[1135630.487426] vfs_write+0x70/0x1c0[1135630.493059] ksys_write+0x5c/0xc8[1135630.498638] __arm64_sys_write+0x24/0x30[1135630.504821] el0_svc_common+0x78/0x130[1135630.510838] el0_svc_handler+0x38/0x78[1135630.516834] el0_svc+0x8/0x1b0kernel/trace/trace_kprobe.c: 13080xffff3df8995039ec : ldr x21, [x24,#120]include/linux/compiler.h: 2940xffff3df8995039f0 : ldr x1, [x21,x0]kernel/trace/trace_kprobe.c1308: head = this_cpu_ptr(call->perf_events);1309: if (hlist_empty(head))1310: return 0;crash> struct trace_event_call -ostruct trace_event_call { ... [120] struct hlist_head *perf_events; //(call->perf_event) ...}crash> struct trace_event_call ffffaf015340e528struct trace_event_call { ... perf_events = 0xffff0ad5fa89f088, //this value is correct, but x21 = 0 ...}Race Condition Analysis:The race occurs between kprobe activation and perf_events initialization: CPU0 CPU1 ==== ==== perf_kprobe_init perf_trace_event_init tp_event->perf_events = list;(1) tp_event->class->reg (2)<- KPROBE ACTIVE Debug exception triggers ... kprobe_dispatcher kprobe_perf_func (tk->tp.flags & TP_FLAG_PROFILE) head = this_cpu_ptr(call->perf_events)(3) (perf_events is still NULL)Problem:1. CPU0 executes (1) assigning tp_event->perf_events = list2. CPU0 executes (2) enabling kprobe functionality via class->reg()3. CPU1 triggers and reaches kprobe_dispatcher4. CPU1 checks TP_FLAG_PROFILE - condition passes (step 2 completed)5. CPU1 calls kprobe_perf_func() and crashes at (3) because call->perf_events is still NULLCPU1 sees that kprobe functionality is enabled but does not see thatperf_events has been assigned.Add pairing read an---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Let userspace take care of interrupt maskRemove the logic to set interrupt mask by default in uio_hv_genericdriver as the interrupt mask value is supposed to be controlledcompletely by the user space. If the mask bit gets changedby the driver, concurrently with user mode operating on the ring,the mask bit may be set when it is supposed to be clear, and theuser-mode driver will miss an interrupt which will cause a hang.For eg- when the driver sets inbound ring buffer interrupt mask to 1,the host does not interrupt the guest on the UIO VMBus channel.However, setting the mask does not prevent the host from putting amessage in the inbound ring buffer. So let's assume that happens,the host puts a message into the ring buffer but does not interrupt.Subsequently, the user space code in the guest sets the inbound ringbuffer interrupt mask to 0, saying "Hey, I'm ready for interrupts".User space code then calls pread() to wait for an interrupt.Then one of two things happens:* The host never sends another message. So the pread() waits forever.* The host does send another message. But because there's already a message in the ring buffer, it doesn't generate an interrupt. This is the correct behavior, because the host should only send an interrupt when the inbound ring buffer transitions from empty to not-empty. Adding an additional message to a ring buffer that is not empty is not supposed to generate an interrupt on the guest. Since the guest is waiting in pread() and not removing messages from the ring buffer, the pread() waits forever.This could be easily reproduced in hv_fcopy_uio_daemon if we delaysetting interrupt mask to 0.Similarly if hv_uio_channel_cb() sets the interrupt_mask to 1,there's a race condition. Once user space empties the inbound ringbuffer, but before user space sets interrupt_mask to 0, the host couldput another message in the ring buffer but it wouldn't interrupt.Then the next pread() would hang.Fix these by removing all instances where interrupt_mask is changed,while keeping the one in set_event() unchanged to enable userspacecontrol the interrupt mask by writing 0/1 to /dev/uioX.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.187.3 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40053 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: dlink: handle copy_thresh allocation failureThe driver did not handle failure of `netdev_alloc_skb_ip_align()`.If the allocation failed, dereferencing `skb->protocol` could lead toa NULL pointer dereference.This patch tries to allocate `skb`. If the allocation fails, it fallsback to the normal path.Tested-on: D-Link DGE-550T Rev-A3

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40055 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix double free in user_cluster_connect()user_cluster_disconnect() frees "conn->cc_private" which is "lc" but thenthe error handling frees "lc" a second time. Set "lc" to NULL on thispath to avoid a double free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40060 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: trbe: Return NULL pointer for allocation failuresWhen the TRBE driver fails to allocate a buffer, it currently returnsthe error code "-ENOMEM". However, the caller etm_setup_aux() onlychecks for a NULL pointer, so it misses the error. As a result, thedriver continues and eventually causes a kernel panic.Fix this by returning a NULL pointer from arm_trbe_alloc_buffer() onallocation failures. This allows that the callers can properly handlethe failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smc: Fix use-after-free in __pnet_find_base_ndev().syzbot reported use-after-free of net_device in __pnet_find_base_ndev(),which was called during connect(). [0]smc_pnet_find_ism_resource() fetches sk_dst_get(sk)->dev and passesdown to pnet_find_base_ndev(), where RTNL is held. Then, UAF happenedat __pnet_find_base_ndev() when the dev is first used.This means dev had already been freed before acquiring RTNL inpnet_find_base_ndev().While dev is going away, dst->dev could be swapped with blackhole_netdev,and the dev's refcnt by dst will be released.We must hold dev's refcnt before calling smc_pnet_find_ism_resource().Also, smc_pnet_find_roce_resource() has the same problem.Let's use __sk_dst_get() and dst_dev_rcu() in the two functions.[0]:BUG: KASAN: use-after-free in __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926Read of size 1 at addr ffff888036bac33a by task syz.0.3632/18609CPU: 1 UID: 0 PID: 18609 Comm: syz.0.3632 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __pnet_find_base_ndev+0x1b1/0x1c0 net/smc/smc_pnet.c:926 pnet_find_base_ndev net/smc/smc_pnet.c:946 [inline] smc_pnet_find_ism_by_pnetid net/smc/smc_pnet.c:1103 [inline] smc_pnet_find_ism_resource+0xef/0x390 net/smc/smc_pnet.c:1154 smc_find_ism_device net/smc/af_smc.c:1030 [inline] smc_find_proposal_devices net/smc/af_smc.c:1115 [inline] __smc_connect+0x372/0x1890 net/smc/af_smc.c:1545 smc_connect+0x877/0xd90 net/smc/af_smc.c:1715 __sys_connect_file net/socket.c:2086 [inline] __sys_connect+0x313/0x440 net/socket.c:2105 __do_sys_connect net/socket.c:2111 [inline] __se_sys_connect net/socket.c:2108 [inline] __x64_sys_connect+0x7a/0x90 net/socket.c:2108 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f47cbf8eba9Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f47ccdb1038 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 00007f47cc1d5fa0 RCX: 00007f47cbf8eba9RDX: 0000000000000010 RSI: 0000200000000280 RDI: 000000000000000bRBP: 00007f47cc011e19 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007f47cc1d6038 R14: 00007f47cc1d5fa0 R15: 00007ffc512f8aa8 The buggy address belongs to the physical page:page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff888036bacd00 pfn:0x36bacflags: 0xfff00000000000(node=0|zone=1|lastcpupid=0x7ff)raw: 00fff00000000000 ffffea0001243d08 ffff8880b863fdc0 0000000000000000raw: ffff888036bacd00 0000000000000000 00000000ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as freedpage last allocated via order 2, migratetype Unmovable, gfp_mask 0x446dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO|__GFP_NOWARN|__GFP_RETRY_MAYFAIL|__GFP_COMP), pid 16741, tgid 16741 (syz-executor), ts 343313197788, free_ts 380670750466 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 __alloc_frozen_pages_noprof+0x181/0x370 mm/page_alloc.c:5148 alloc_pages_mpol+0x232/0x4a0 mm/mempolicy.c:2416 ___kmalloc_large_node+0x5f/0x1b0 mm/slub.c:4317 __kmalloc_large_node_noprof+0x18/0x90 mm/slub.c:4348 __do_kmalloc_node mm/slub.c:4364 [inline] __kvmalloc_node---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40071 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: Don't block input queue by waiting MSCCurrently gsm_queue() processes incoming frames and when openinga DLC channel it calls gsm_dlci_open() which calls gsm_modem_update().If basic mode is used it calls gsm_modem_upd_via_msc() and itcannot block the input queue by waiting the response to comeinto the same input queue.Instead allow sending Modem Status Command without waiting for remoteend to respond. Define a new function gsm_modem_send_initial_msc()for this purpose. As MSC is only valid for basic encoding, it doesnot do anything for advanced or when convergence layer type 2 is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: start using dst_dev_rcu()Change icmpv4_xrlim_allow(), ip_defrag() to prevent possible UAF.Change ipmr_prepare_xmit(), ipmr_queue_fwd_xmit(), ip_mr_output(),ipv4_neigh_lookup() to use lockdep enabled dst_dev_rcu().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: use dst_dev_net_rcu()Replace three dst_dev() with a lockdep enabled helper.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Explicitly check accesses to bpf_sock_addrSyzkaller found a kernel warning on the following sock_addr program: 0: r0 = 0 1: r2 = *(u32 *)(r1 +60) 2: exitwhich triggers: verifier bug: error during ctx access conversion (0)This is happening because offset 60 in bpf_sock_addr corresponds to animplicit padding of 4 bytes, right after msg_src_ip4. Access to thispadding isn't rejected in sock_addr_is_valid_access and it thus laterfails to convert the access.This patch fixes it by explicitly checking the various fields ofbpf_sock_addr in sock_addr_is_valid_access.I checked the other ctx structures and is_valid_access functions anddidn't find any other similar cases. Other cases of (properly handled)padding are covered in new tests in a subsequent patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40080 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: restrict sockets to TCP and UDPRecently, syzbot started to abuse NBD with all kinds of sockets.Commit cf1b2326b734 ("nbd: verify socket is supported during setup")made sure the socket supported a shutdown() method.Explicitely accept TCP and UNIX stream sockets.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40081 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf: arm_spe: Prevent overflow in PERF_IDX2OFF()Cast nr_pages to unsigned long to avoid overflow when handling largeAUX buffer sizes (>= 2 GiB).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix null-deref in agg_dequeueTo prevent a potential crash in agg_dequeue (net/sched/sch_qfq.c)when cl->qdisc->ops->peek(cl->qdisc) returns NULL, we check the returnvalue before using it, similar to the existing approach in sch_hfsc.c.To avoid code duplication, the following changes are made:1. Changed qdisc_warn_nonwc(include/net/pkt_sched.h) into a staticinline function.2. Moved qdisc_peek_len from net/sched/sch_hfsc.c toinclude/net/pkt_sched.h so that sch_qfq can reuse it.3. Applied qdisc_peek_len in agg_dequeue to avoid crashing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40087 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Define a proc_layoutcommit for the FlexFiles layout typeAvoid a crash if a pNFS client should happen to send a LAYOUTCOMMIToperation on a FlexFiles layout.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40092 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ncm: Refactor bind path to use __free()After an bind/unbind cycle, the ncm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020Call trace: usb_ep_free_request+0x2c/0xec ncm_bind+0x39c/0x3dc usb_add_function+0xcc/0x1f0 configfs_composite_bind+0x468/0x588 gadget_bind_driver+0x104/0x270 really_probe+0x190/0x374 __driver_probe_device+0xa0/0x12c driver_probe_device+0x3c/0x218 __device_attach_driver+0x14c/0x188 bus_for_each_drv+0x10c/0x168 __device_attach+0xfc/0x198 device_initial_probe+0x14/0x24 bus_probe_device+0x94/0x11c device_add+0x268/0x48c usb_add_gadget+0x198/0x28c dwc3_gadget_init+0x700/0x858 __dwc3_set_mode+0x3cc/0x664 process_scheduled_works+0x1d8/0x488 worker_thread+0x244/0x334 kthread+0x114/0x1bc ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40093 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_ecm: Refactor bind path to use __free()After an bind/unbind cycle, the ecm->notify_req is left stale. If asubsequent bind fails, the unified error label attempts to free thisstale request, leading to a NULL pointer dereference when accessingep->ops->free_request.Refactor the error handling in the bind path to use the __free()automatic cleanup mechanism.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40097 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Fix missing pointer check in hda_component_manager_init functionThe __component_match_add function may assign the 'matchptr' pointerthe value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.The call stack leading to the error looks like this:hda_component_manager_init|-> component_match_add |-> component_match_add_release |-> __component_match_add ( ... ,**matchptr, ... ) |-> *matchptr = ERR_PTR(-ENOMEM); // assign|-> component_master_add_with_match( ... match) |-> component_match_realloc(match, match->num); // dereferenceAdd IS_ERR() check to prevent the crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40100 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not assert we found block group item when creating free space treeCurrently, when building a free space tree at populate_free_space_tree(),if we are not using the block group tree feature, we always expect to findblock group items (either extent items or a block group item with key typeBTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree withbtrfs_search_slot_for_read(), so we assert that we found an item. Howeverthis expectation is wrong since we can have a new block group created inthe current transaction which is still empty and for which we still havenot added the block group's item to the extent tree, in which case we donot have any items in the extent tree associated to the block group.The insertion of a new block group's block group item in the extent treehappens at btrfs_create_pending_block_groups() when it calls the helperinsert_block_group_item(). This typically is done when a transactionhandle is released, committed or when running delayed refs (either aspart of a transaction commit or when serving tickets for space reservationif we are low on free space).So remove the assertion at populate_free_space_tree() even when the blockgroup tree feature is not enabled and update the comment to mention thiscase.Syzbot reported this with the following stack trace: BTRFS info (device loop3 state M): rebuilding free space tree assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115 ------------[ cut here ]------------ kernel BUG at fs/btrfs/free-space-tree.c:1115! Oops: invalid opcode: 0000 [#1] SMP KASAN PTI CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115 Code: ff ff e8 d3 (...) RSP: 0018:ffffc9000430f780 EFLAGS: 00010246 RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000 RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000 RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94 R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001 R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000 FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0 Call Trace: btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364 btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062 btrfs_remount_rw fs/btrfs/super.c:1334 [inline] btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559 reconfigure_super+0x227/0x890 fs/super.c:1076 do_remount fs/namespace.c:3279 [inline] path_mount+0xd1a/0xfe0 fs/namespace.c:4027 do_mount fs/namespace.c:4048 [inline] __do_sys_mount fs/namespace.c:4236 [inline] __se_sys_mount+0x313/0x410 fs/namespace.c:4213 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f424e39066a Code: d8 64 89 02 (...) RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5 RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000 RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020 R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380 R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0 Modules linked in: ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: fix divide-by-zero in comedi_buf_munge()The comedi_buf_munge() function performs a modulo operation`async->munge_chan %= async->cmd.chanlist_len` without firstchecking if chanlist_len is zero. If a user program submits a command withchanlist_len set to zero, this causes a divide-by-zero error when the deviceprocesses data in the interrupt handler path.Add a check for zero chanlist_len at the beginning of thefunction, similar to the existing checks for !map andCMDF_RAWDATA flag. When chanlist_len is zero, updatemunge_count and return early, indicating the data washandled without munging.This prevents potential kernel panics from malformed user commands.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40109 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: rng - Ensure set_ent is always presentEnsure that set_ent is always set since only drbg provides it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40115 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Fix crash in transport port remove by using ioc_info()During mpt3sas_transport_port_remove(), messages were logged withdev_printk() against &mpt3sas_port->port->dev. At this point the SAStransport device may already be partially unregistered or freed, leadingto a crash when accessing its struct device.Using ioc_info(), which logs via the PCI device (ioc->pdev->dev),guaranteed to remain valid until driver removal.[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G OE 6.16.0-rc1+ #1 PREEMPT(voluntary)[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30[83428.295833] FS: 00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000[83428.295837] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0[83428.295844] PKRU: 55555554[83428.295846] Call Trace:[83428.295848] [83428.295850] _dev_printk+0x5c/0x80[83428.295857] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295863] mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas][83428.295882] _scsih_remove_device+0x21b/0x280 [mpt3sas][83428.295894] ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas][83428.295906] ? srso_alias_return_thunk+0x5/0xfbef5[83428.295910] mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas][83428.295921] _scsih_expander_node_remove+0x129/0x140 [mpt3sas][83428.295933] _scsih_expander_node_remove+0x6a/0x140 [mpt3sas][83428.295944] scsih_remove+0x3f0/0x4a0 [mpt3sas][83428.295957] pci_device_remove+0x3b/0xb0[83428.295962] device_release_driver_internal+0x193/0x200[83428.295968] driver_detach+0x44/0x90[83428.295971] bus_remove_driver+0x69/0xf0[83428.295975] pci_unregister_driver+0x2a/0xb0[83428.295979] _mpt3sas_exit+0x1f/0x300 [mpt3sas][83428.295991] __do_sys_delete_module.constprop.0+0x174/0x310[83428.295997] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296000] ? __x64_sys_getdents64+0x9a/0x110[83428.296005] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296009] ? syscall_trace_enter+0xf6/0x1b0[83428.296014] do_syscall_64+0x7b/0x2c0[83428.296019] ? srso_alias_return_thunk+0x5/0xfbef5[83428.296023] entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40116 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: host: max3421-hcd: Fix error pointer dereference in probe cleanupThe kthread_run() function returns error pointers so themax3421_hcd->spi_thread pointer can be either error pointers or NULL.Check for both before dereferencing it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40123 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Enforce expected_attach_type for tailcall compatibilityYinhao et al. recently reported: Our fuzzer tool discovered an uninitialized pointer issue in the bpf_prog_test_run_xdp() function within the Linux kernel's BPF subsystem. This leads to a NULL pointer dereference when a BPF program attempts to deference the txq member of struct xdp_buff object.The test initializes two programs of BPF_PROG_TYPE_XDP: progA acts as theentry point for bpf_prog_test_run_xdp() and its expected_attach_type canneither be of be BPF_XDP_DEVMAP nor BPF_XDP_CPUMAP. progA calls into a slotof a tailcall map it owns. progB's expected_attach_type must be BPF_XDP_DEVMAPto pass xdp_is_valid_access() validation. The program returns struct xdp_md'segress_ifindex, and the latter is only allowed to be accessed under mentionedexpected_attach_type. progB is then inserted into the tailcall which progAcalls.The underlying issue goes beyond XDP though. Another example are programsof type BPF_PROG_TYPE_CGROUP_SOCK_ADDR. sock_addr_is_valid_access() as wellas sock_addr_func_proto() have different logic depending on the programs'expected_attach_type. Similarly, a program attached to BPF_CGROUP_INET4_GETPEERNAMEshould not be allowed doing a tailcall into a program which calls bpf_bind()out of BPF which is only enabled for BPF_CGROUP_INET4_CONNECT.In short, specifying expected_attach_type allows to open up additionalfunctionality or restrictions beyond what the basic bpf_prog_type enables.The use of tailcalls must not violate these constraints. Fix it by enforcingexpected_attach_type in __bpf_prog_map_compatible().Note that we only enforce this for tailcall maps, but not for BPF devmaps orcpumaps: There, the programs are invoked through dev_map_bpf_prog_run*() andcpu_map_bpf_prog_run*() which set up a new environment / context and thereforethese situations are not prone to this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40124 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sparc: fix accurate exception reporting in copy_{from_to}_user for UltraSPARC IIIAnthony Yznaga tracked down that a BUG_ON in ext4 code with large foliosenabled resulted from copy_from_user() returning impossibly large valuesgreater than the size to be copied. This lead to __copy_from_iter()returning impossible values instead of the actual number of bytes it wasable to copy.The BUG_ON has been reported inhttps://lore.kernel.org/r/b14f55642207e63e907965e209f6323a0df6dcee.camel@physik.fu-berlin.deThe referenced commit introduced exception handlers on user-space memoryreferences in copy_from_user and copy_to_user. These handlers return fromthe respective function and calculate the remaining bytes left to copyusing the current register contents. The exception handlers expect that%o2 has already been masked during the bulk copy loop, but the masking wasperformed after that loop. This will fix the return value of copy_from_userand copy_to_user in the faulting case. The behaviour of memcpy staysunchanged.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40125 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: check kobject state_in_sysfs before deleting in blk_mq_unregister_hctxIn __blk_mq_update_nr_hw_queues() the return value ofblk_mq_sysfs_register_hctxs() is not checked. If sysfs creation for hctxfails, later changing the number of hw_queues or removing disk willtrigger the following warning: kernfs: can not remove 'nr_tags', no directory WARNING: CPU: 2 PID: 637 at fs/kernfs/dir.c:1707 kernfs_remove_by_name_ns+0x13f/0x160 Call Trace: remove_files.isra.1+0x38/0xb0 sysfs_remove_group+0x4d/0x100 sysfs_remove_groups+0x31/0x60 __kobject_del+0x23/0xf0 kobject_del+0x17/0x40 blk_mq_unregister_hctx+0x5d/0x80 blk_mq_sysfs_unregister_hctxs+0x94/0xd0 blk_mq_update_nr_hw_queues+0x124/0x760 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x92/0x120 [null_blk]kobjct_del() was called unconditionally even if sysfs creation failed.Fix it by checkig the kobject creation statusbefore deleting it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40127 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: ks-sa - fix division by zero in ks_sa_rng_initFix division by zero in ks_sa_rng_init caused by missing clockpointer initialization. The clk_get_rate() call is performed onan uninitialized clk pointer, resulting in division by zero whencalculating delay values.Add clock initialization code before using the clock. drivers/char/hw_random/ks-sa-rng.c | 7 +++++++ 1 file changed, 7 insertions(+)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40167 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: detect invalid INLINE_DATA + EXTENTS flag combinationsyzbot reported a BUG_ON in ext4_es_cache_extent() when opening a verityfile on a corrupted ext4 filesystem mounted without a journal.The issue is that the filesystem has an inode with both the INLINE_DATAand EXTENTS flags set: EXT4-fs error (device loop0): ext4_cache_extents:545: inode #15: comm syz.0.17: corrupted extent tree: lblk 0 < prev 66Investigation revealed that the inode has both flags set: DEBUG: inode 15 - flag=1, i_inline_off=164, has_inline=1, extents_flag=1This is an invalid combination since an inode should have either:- INLINE_DATA: data stored directly in the inode- EXTENTS: data stored in extent-mapped blocksHaving both flags causes ext4_has_inline_data() to return true, skippingextent tree validation in __ext4_iget(). The unvalidated out-of-orderextents then trigger a BUG_ON in ext4_es_cache_extent() due to integerunderflow when calculating hole sizes.Fix this by detecting this invalid flag combination early in ext4_iget()and rejecting the corrupted inode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40188 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pwm: berlin: Fix wrong register in suspend/resumeThe 'enable' register should be BERLIN_PWM_EN rather thanBERLIN_PWM_ENABLE, otherwise, the driver accesses wrong address, therewill be cpu exception then kernel panic during suspend/resume.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40198 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid potential buffer over-read in parse_apply_sb_mount_options()Unlike other strings in the ext4 superblock, we rely on tune2fs tomake sure s_mount_opts is NUL terminated. Hardenparse_apply_sb_mount_options() by treating s_mount_opts as a potential__nonstring.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40200 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Squashfs: reject negative file sizes in squashfs_read_inode()Syskaller reports a "WARNING in ovl_copy_up_file" in overlayfs.This warning is ultimately caused because the underlying Squashfs filesystem returns a file with a negative file size.This commit checks for a negative file size and returns EINVAL.[phillip@squashfs.org.uk: only need to check 64 bit quantity]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40205 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: avoid potential out-of-bounds in btrfs_encode_fh()The function btrfs_encode_fh() does not properly account for the threecases it handles.Before writing to the file handle (fh), the function only returns to theuser BTRFS_FID_SIZE_NON_CONNECTABLE (5 dwords, 20 bytes) orBTRFS_FID_SIZE_CONNECTABLE (8 dwords, 32 bytes).However, when a parent exists and the root ID of the parent and theinode are different, the function writes BTRFS_FID_SIZE_CONNECTABLE_ROOT(10 dwords, 40 bytes).If *max_len is not large enough, this write goes out of bounds becauseBTRFS_FID_SIZE_CONNECTABLE_ROOT is greater thanBTRFS_FID_SIZE_CONNECTABLE originally returned.This results in an 8-byte out-of-bounds write atfid->parent_root_objectid = parent_root_id.A previous attempt to fix this issue was made but was lost.https://lore.kernel.org/all/4CADAEEC020000780001B32C@vpn.id2.novell.com/Although this issue does not seem to be easily triggerable, it is apotential memory corruption bug that should be fixed. This patchresolves the issue by ensuring the function returns the appropriate sizefor all three cases and validates that *max_len is large enough beforewriting any data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: Fix use-after-free in hdm_disconnecthdm_disconnect() calls most_deregister_interface(), which eventuallyunregisters the MOST interface device with device_unregister(iface->dev).If that drops the last reference, the device core may call release_mdev()immediately while hdm_disconnect() is still executing.The old code also freed several mdev-owned allocations inhdm_disconnect() and then performed additional put_device() calls.Depending on refcount order, this could lead to use-after-free ordouble-free when release_mdev() ran (or when unregister paths alsoperformed puts).Fix by moving the frees of mdev-owned allocations into release_mdev(),so they happen exactly once when the device is truly released, and bydropping the extra put_device() calls in hdm_disconnect() that areredundant after device_unregister() and most_deregister_interface().This addresses the KASAN slab-use-after-free reported by syzbot inhdm_disconnect(). See report and stack traces in the bug link below.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: clear extent cache after moving/defragmenting extentsThe extent map cache can become stale when extents are moved ordefragmented, causing subsequent operations to see outdated extent flags. This triggers a BUG_ON in ocfs2_refcount_cal_cow_clusters().The problem occurs when:1. copy_file_range() creates a reflinked extent with OCFS2_EXT_REFCOUNTED2. ioctl(FITRIM) triggers ocfs2_move_extents()3. __ocfs2_move_extents_range() reads and caches the extent (flags=0x2)4. ocfs2_move_extent()/ocfs2_defrag_extent() calls __ocfs2_move_extent() which clears OCFS2_EXT_REFCOUNTED flag on disk (flags=0x0)5. The extent map cache is not invalidated after the move6. Later write() operations read stale cached flags (0x2) but disk has updated flags (0x0), causing a mismatch7. BUG_ON(!(rec->e_flags & OCFS2_EXT_REFCOUNTED)) triggersFix by clearing the extent map cache after each extent move/defragoperation in __ocfs2_move_extents_range(). This ensures subsequentoperations read fresh extent data from disk.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40240 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: avoid NULL dereference when chunk data buffer is missingchunk->skb pointer is dereferenced in the if-block where it's supposedto be NULL only.chunk->skb can only be NULL if chunk->head_skb is not. Check for frag_listinstead and do it just before replacing chunk->skb. We're sure thatotherwise chunk->skb is non-NULL because of outer if() condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40248 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Ignore signal/timeout on connect() if already establishedDuring connect(), acting on a signal/timeout by disconnecting an alreadyestablished socket leads to several issues:1. connect() invoking vsock_transport_cancel_pkt() -> virtio_transport_purge_skbs() may race with sendmsg() invoking virtio_transport_get_credit(). This results in a permanently elevated `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.2. connect() resetting a connected socket's state may race with socket being placed in a sockmap. A disconnected socket remaining in a sockmap breaks sockmap's assumptions. And gives rise to WARNs.3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a transport change/drop after TCP_ESTABLISHED. Which poses a problem for any simultaneous sendmsg() or connect() and may result in a use-after-free/null-ptr-deref.Do not disconnect socket on signal/timeout. Keep the logic for unconnectedsockets: they don't linger, can't be placed in a sockmap, are rejected bysendmsg().[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40251 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:devlink: rate: Unset parent pointer in devl_rate_nodes_destroyThe function devl_rate_nodes_destroy is documented to "Unset parent forall rate objects". However, it was only calling the driver-specific`rate_leaf_parent_set` or `rate_node_parent_set` ops and decrementingthe parent's refcount, without actually setting the`devlink_rate->parent` pointer to NULL.This leaves a dangling pointer in the `devlink_rate` struct, which causerefcount error in netdevsim[1] and mlx5[2]. In addition, this isinconsistent with the behavior of `devlink_nl_rate_parent_node_set`,where the parent pointer is correctly cleared.This patch fixes the issue by explicitly setting `devlink_rate->parent`to NULL after notifying the driver, thus fulfilling the function'sdocumented behavior for all rate objects.[1]repro steps:echo 1 > /sys/bus/netdevsim/new_devicedevlink dev eswitch set netdevsim/netdevsim1 mode switchdevecho 1 > /sys/bus/netdevsim/devices/netdevsim1/sriov_numvfsdevlink port function rate add netdevsim/netdevsim1/test_nodedevlink port function rate set netdevsim/netdevsim1/128 parent test_nodeecho 1 > /sys/bus/netdevsim/del_devicedmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 8 PID: 1530 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 8 UID: 0 PID: 1530 Comm: bash Not tainted 6.18.0-rc4+ #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 __nsim_dev_port_del+0x6c/0x70 [netdevsim] nsim_dev_reload_destroy+0x11c/0x140 [netdevsim] nsim_drv_remove+0x2b/0xb0 [netdevsim] device_release_driver_internal+0x194/0x1f0 bus_remove_device+0xc6/0x130 device_del+0x159/0x3c0 device_unregister+0x1a/0x60 del_device_store+0x111/0x170 [netdevsim] kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x55/0x10f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53[2]devlink dev eswitch set pci/0000:08:00.0 mode switchdevdevlink port add pci/0000:08:00.0 flavour pcisf pfnum 0 sfnum 1000devlink port function rate add pci/0000:08:00.0/group1devlink port function rate set pci/0000:08:00.0/32768 parent group1modprobe -r mlx5_ib mlx5_fwctl mlx5_coredmesg:refcount_t: decrement hit 0; leaking memory.WARNING: CPU: 7 PID: 16151 at lib/refcount.c:31 refcount_warn_saturate+0x42/0xe0CPU: 7 UID: 0 PID: 16151 Comm: bash Not tainted 6.17.0-rc7_for_upstream_min_debug_2025_10_02_12_44 #1 NONEHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:refcount_warn_saturate+0x42/0xe0Call Trace: devl_rate_leaf_destroy+0x8d/0x90 mlx5_esw_offloads_devlink_port_unregister+0x33/0x60 [mlx5_core] mlx5_esw_offloads_unload_rep+0x3f/0x50 [mlx5_core] mlx5_eswitch_unload_sf_vport+0x40/0x90 [mlx5_core] mlx5_sf_esw_event+0xc4/0x120 [mlx5_core] notifier_call_chain+0x33/0xa0 blocking_notifier_call_chain+0x3b/0x50 mlx5_eswitch_disable_locked+0x50/0x110 [mlx5_core] mlx5_eswitch_disable+0x63/0x90 [mlx5_core] mlx5_unload+0x1d/0x170 [mlx5_core] mlx5_uninit_one+0xa2/0x130 [mlx5_core] remove_one+0x78/0xd0 [mlx5_core] pci_device_remove+0x39/0xa0 device_release_driver_internal+0x194/0x1f0 unbind_store+0x99/0xa0 kernfs_fop_write_iter+0x12e/0x1e0 vfs_write+0x215/0x3d0 ksys_write+0x5f/0xd0 do_syscall_64+0x53/0x1f0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40252 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: qlogic/qede: fix potential out-of-bounds read in qede_tpa_cont() and qede_tpa_end()The loops in 'qede_tpa_cont()' and 'qede_tpa_end()', iterateover 'cqe->len_list[]' using only a zero-length terminator asthe stopping condition. If the terminator was missing ormalformed, the loop could run past the end of the fixed-size array.Add an explicit bound check using ARRAY_SIZE() in both loops to preventa potential out-of-bounds access.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40253 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/ctcm: Fix double-kfreeThe function 'mpc_rcvd_sweep_req(mpcginfo)' is called conditionallyfrom function 'ctcmpc_unpack_skb'. It frees passed mpcginfo.After that a call to function 'kfree' in function 'ctcmpc_unpack_skb'frees it again.Remove 'kfree' call in function 'mpc_rcvd_sweep_req(mpcginfo)'.Bug detected by the clang static analyzer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40254 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: remove never-working support for setting nsh fieldsThe validation of the set(nsh(...)) action is completely wrong.It runs through the nsh_key_put_from_nlattr() function that is thesame function that validates NSH keys for the flow match and thepush_nsh() action. However, the set(nsh(...)) has a very differentmemory layout. Nested attributes in there are doubled in size incase of the masked set(). That makes proper validation impossible.There is also confusion in the code between the 'masked' flag, thatsays that the nested attributes are doubled in size containing boththe value and the mask, and the 'is_mask' that says that the valuewe're parsing is the mask. This is causing kernel crash on trying towrite into mask part of the match with SW_FLOW_KEY_PUT() duringvalidation, while validate_nsh() doesn't allocate any memory for it: BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nsh_key_put_from_nlattr+0x19d/0x610 [openvswitch] Call Trace: validate_nsh+0x60/0x90 [openvswitch] validate_set.constprop.0+0x270/0x3c0 [openvswitch] __ovs_nla_copy_actions+0x477/0x860 [openvswitch] ovs_nla_copy_actions+0x8d/0x100 [openvswitch] ovs_packet_cmd_execute+0x1cc/0x310 [openvswitch] genl_family_rcv_msg_doit+0xdb/0x130 genl_family_rcv_msg+0x14b/0x220 genl_rcv_msg+0x47/0xa0 netlink_rcv_skb+0x53/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x280/0x3b0 netlink_sendmsg+0x1f7/0x430 ____sys_sendmsg+0x36b/0x3a0 ___sys_sendmsg+0x87/0xd0 __sys_sendmsg+0x6d/0xd0 do_syscall_64+0x7b/0x2c0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe third issue with this process is that while trying to convertthe non-masked set into masked one, validate_set() copies and doublesthe size of the OVS_KEY_ATTR_NSH as if it didn't have any nestedattributes. It should be copying each nested attribute and doublingthem in size independently. And the process must be properly reversedduring the conversion back from masked to a non-masked variant duringthe flow dump.In the end, the only two outcomes of trying to use this action areeither validation failure or a kernel crash. And if somehow someonemanages to install a flow with such an action, it will most definitelynot do what it is supposed to, since all the keys and the masks aremixed up.Fixing all the issues is a complex task as it requires re-writingmost of the validation code.Given that and the fact that this functionality never worked sinceintroduction, let's just remove it altogether. It's better tore-introduce it later with a proper implementation instead of tryingto fix it in stable releases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40257 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: fix a race in mptcp_pm_del_add_timer()mptcp_pm_del_add_timer() can call sk_stop_timer_sync(sk, &entry->add_timer)while another might have free entry already, as reported by syzbot.Add RCU protection to fix this issue.Also change confusing add_timer variable with stop_timer boolean.syzbot report:BUG: KASAN: slab-use-after-free in __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616Read of size 4 at addr ffff8880311e4150 by task kworker/1:1/44CPU: 1 UID: 0 PID: 44 Comm: kworker/1:1 Not tainted syzkaller #0 PREEMPT_{RT,(full)}Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025Workqueue: events mptcp_workerCall Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:378 [inline] print_report+0xca/0x240 mm/kasan/report.c:482 kasan_report+0x118/0x150 mm/kasan/report.c:595 __timer_delete_sync+0x372/0x3f0 kernel/time/timer.c:1616 sk_stop_timer_sync+0x1b/0x90 net/core/sock.c:3631 mptcp_pm_del_add_timer+0x283/0x310 net/mptcp/pm.c:362 mptcp_incoming_options+0x1357/0x1f60 net/mptcp/options.c:1174 tcp_data_queue+0xca/0x6450 net/ipv4/tcp_input.c:5361 tcp_rcv_established+0x1335/0x2670 net/ipv4/tcp_input.c:6441 tcp_v4_do_rcv+0x98b/0xbf0 net/ipv4/tcp_ipv4.c:1931 tcp_v4_rcv+0x252a/0x2dc0 net/ipv4/tcp_ipv4.c:2374 ip_protocol_deliver_rcu+0x221/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x3bb/0x6f0 net/ipv4/ip_input.c:239 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 NF_HOOK+0x30c/0x3a0 include/linux/netfilter.h:318 __netif_receive_skb_one_core net/core/dev.c:6079 [inline] __netif_receive_skb+0x143/0x380 net/core/dev.c:6192 process_backlog+0x31e/0x900 net/core/dev.c:6544 __napi_poll+0xb6/0x540 net/core/dev.c:7594 napi_poll net/core/dev.c:7657 [inline] net_rx_action+0x5f7/0xda0 net/core/dev.c:7784 handle_softirqs+0x22f/0x710 kernel/softirq.c:622 __do_softirq kernel/softirq.c:656 [inline] __local_bh_enable_ip+0x1a0/0x2e0 kernel/softirq.c:302 mptcp_pm_send_ack net/mptcp/pm.c:210 [inline] mptcp_pm_addr_send_ack+0x41f/0x500 net/mptcp/pm.c:-1 mptcp_pm_worker+0x174/0x320 net/mptcp/pm.c:1002 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 Allocated by task 44: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 poison_kmalloc_redzone mm/kasan/common.c:400 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:417 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x1ef/0x6c0 mm/slub.c:5748 kmalloc_noprof include/linux/slab.h:957 [inline] mptcp_pm_alloc_anno_list+0x104/0x460 net/mptcp/pm.c:385 mptcp_pm_create_subflow_or_signal_addr+0xf9d/0x1360 net/mptcp/pm_kernel.c:355 mptcp_pm_nl_fully_established net/mptcp/pm_kernel.c:409 [inline] __mptcp_pm_kernel_worker+0x417/0x1ef0 net/mptcp/pm_kernel.c:1529 mptcp_pm_worker+0x1ee/0x320 net/mptcp/pm.c:1008 mptcp_worker+0xd5/0x1170 net/mptcp/protocol.c:2762 process_one_work kernel/workqueue.c:3263 [inline] process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3346 worker_thread+0x8a0/0xda0 kernel/workqueue.c:3427 kthread+0x711/0x8a0 kernel/kthread.c:463 ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245Freed by task 6630: kasan_save_stack mm/kasan/common.c:56 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:77 __kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:587 kasan_save_free_info mm/kasan/kasan.h:406 [inline] poison_slab_object m---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: sg: Do not sleep in atomic contextsg_finish_rem_req() calls blk_rq_unmap_user(). The latter function maysleep. Hence, call sg_finish_rem_req() with interrupts enabled insteadof disabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme: nvme-fc: Ensure ->ioerr_work is cancelled in nvme_fc_delete_ctrl()nvme_fc_delete_assocation() waits for pending I/O to complete beforereturning, and an error can cause ->ioerr_work to be queued aftercancel_work_sync() had been called. Move the call to cancel_work_sync() tobe after nvme_fc_delete_association() to ensure ->ioerr_work is not runningwhen the nvme_fc_ctrl object is freed. Otherwise the following can occur:[ 1135.911754] list_del corruption, ff2d24c8093f31f8->next is NULL[ 1135.917705] ------------[ cut here ]------------[ 1135.922336] kernel BUG at lib/list_debug.c:52![ 1135.926784] Oops: invalid opcode: 0000 [#1] SMP NOPTI[ 1135.931851] CPU: 48 UID: 0 PID: 726 Comm: kworker/u449:23 Kdump: loaded Not tainted 6.12.0 #1 PREEMPT(voluntary)[ 1135.943490] Hardware name: Dell Inc. PowerEdge R660/0HGTK9, BIOS 2.5.4 01/16/2025[ 1135.950969] Workqueue: 0x0 (nvme-wq)[ 1135.954673] RIP: 0010:__list_del_entry_valid_or_report.cold+0xf/0x6f[ 1135.961041] Code: c7 c7 98 68 72 94 e8 26 45 fe ff 0f 0b 48 c7 c7 70 68 72 94 e8 18 45 fe ff 0f 0b 48 89 fe 48 c7 c7 80 69 72 94 e8 07 45 fe ff <0f> 0b 48 89 d1 48 c7 c7 a0 6a 72 94 48 89 c2 e8 f3 44 fe ff 0f 0b[ 1135.979788] RSP: 0018:ff579b19482d3e50 EFLAGS: 00010046[ 1135.985015] RAX: 0000000000000033 RBX: ff2d24c8093f31f0 RCX: 0000000000000000[ 1135.992148] RDX: 0000000000000000 RSI: ff2d24d6bfa1d0c0 RDI: ff2d24d6bfa1d0c0[ 1135.999278] RBP: ff2d24c8093f31f8 R08: 0000000000000000 R09: ffffffff951e2b08[ 1136.006413] R10: ffffffff95122ac8 R11: 0000000000000003 R12: ff2d24c78697c100[ 1136.013546] R13: fffffffffffffff8 R14: 0000000000000000 R15: ff2d24c78697c0c0[ 1136.020677] FS: 0000000000000000(0000) GS:ff2d24d6bfa00000(0000) knlGS:0000000000000000[ 1136.028765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 1136.034510] CR2: 00007fd207f90b80 CR3: 000000163ea22003 CR4: 0000000000f73ef0[ 1136.041641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 1136.048776] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 1136.055910] PKRU: 55555554[ 1136.058623] Call Trace:[ 1136.061074] [ 1136.063179] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.067540] ? show_trace_log_lvl+0x1b0/0x2f0[ 1136.071898] ? move_linked_works+0x4a/0xa0[ 1136.075998] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.081744] ? __die_body.cold+0x8/0x12[ 1136.085584] ? die+0x2e/0x50[ 1136.088469] ? do_trap+0xca/0x110[ 1136.091789] ? do_error_trap+0x65/0x80[ 1136.095543] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.101289] ? exc_invalid_op+0x50/0x70[ 1136.105127] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.110874] ? asm_exc_invalid_op+0x1a/0x20[ 1136.115059] ? __list_del_entry_valid_or_report.cold+0xf/0x6f[ 1136.120806] move_linked_works+0x4a/0xa0[ 1136.124733] worker_thread+0x216/0x3a0[ 1136.128485] ? __pfx_worker_thread+0x10/0x10[ 1136.132758] kthread+0xfa/0x240[ 1136.135904] ? __pfx_kthread+0x10/0x10[ 1136.139657] ret_from_fork+0x31/0x50[ 1136.143236] ? __pfx_kthread+0x10/0x10[ 1136.146988] ret_from_fork_asm+0x1a/0x30[ 1136.150915]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40262 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: imx_sc_key - fix memory corruption on unloadThis is supposed to be "priv" but we accidentally pass "&priv" which isan address in the stack and so it will lead to memory corruption whenthe imx_sc_key_action() function is called. Remove the &.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40263 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: cros_ec_keyb - fix an invalid memory accessIf cros_ec_keyb_register_matrix() isn't called (due to`buttons_switches_only`) in cros_ec_keyb_probe(), `ckdev->idev` remainsNULL. An invalid memory access is observed in cros_ec_keyb_process()when receiving an EC_MKBP_EVENT_KEY_MATRIX event in cros_ec_keyb_work()in such case. Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: input_event cros_ec_keyb_work blocking_notifier_call_chain ec_irq_threadIt's still unknown about why the kernel receives such malformed event,in any cases, the kernel shouldn't access `ckdev->idev` and friends ifthe driver doesn't intend to initialize them.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:be2net: pass wrb_params in case of OS2BMCbe_insert_vlan_in_pkt() is called with the wrb_params argument being NULLat be_send_pkt_to_bmc() call site. This may lead to dereferencing a NULLpointer when processing a workaround for specific packet, as commitbc0c3405abbb ("be2net: fix a Tx stall bug caused by a specific ipv6packet") states.The correct way would be to pass the wrb_params from be_xmit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40269 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential overflow of PCM transfer bufferThe PCM stream data in USB-audio driver is transferred over USB URBpacket buffers, and each packet size is determined dynamically. Thepacket sizes are limited by some factors such as wMaxPacketSize USBdescriptor. OTOH, in the current code, the actually used packet sizesare determined only by the rate and the PPS, which may be bigger thanthe size limit above. This results in a buffer overflow, as reportedby syzbot.Basically when the limit is smaller than the calculated packet size,it implies that something is wrong, most likely a weird USBdescriptor. So the best option would be just to return an error atthe parameter setup time before doing any further operations.This patch introduces such a sanity check, and returns -EINVAL whenthe packet size is greater than maxpacksize. The comparison withep->packsize[1] alone should suffice since it's always equal orgreater than ep->packsize[0].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40272 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/secretmem: fix use-after-free race in fault handlerWhen a page fault occurs in a secret memory file created with`memfd_secret(2)`, the kernel will allocate a new folio for it, mark theunderlying page as not-present in the direct map, and add it to the filemapping.If two tasks cause a fault in the same page concurrently, both could endup allocating a folio and removing the page from the direct map, but onlyone would succeed in adding the folio to the file mapping. The task thatfailed undoes the effects of its attempt by (a) freeing the folio againand (b) putting the page back into the direct map. However, by doingthese two operations in this order, the page becomes available to theallocator again before it is placed back in the direct mapping.If another task attempts to allocate the page between (a) and (b), and thekernel tries to access it via the direct map, it would result in asupervisor not-present page fault.Fix the ordering to restore the direct map before the folio is freed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40273 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: free copynotify stateid in nfs4_free_ol_stateid()Typically copynotify stateid is freed either when parent's stateidis being close/freed or in nfsd4_laundromat if the stateid hasn'tbeen used in a lease period.However, in case when the server got an OPEN (which createda parent stateid), followed by a COPY_NOTIFY using that stateid,followed by a client reboot. New client instance while doingCREATE_SESSION would force expire previous state of this client.It leads to the open state being freed thru release_openowner->nfs4_free_ol_stateid() and it finds that it still has copynotifystateid associated with it. We currently print a warning and istriggerredWARNING: CPU: 1 PID: 8858 at fs/nfsd/nfs4state.c:1550 nfs4_free_ol_stateid+0xb0/0x100 [nfsd]This patch, instead, frees the associated copynotify stateid here.If the parent stateid is freed (without freeing the copynotifystateids associated with it), it leads to the list corruptionwhen laundromat ends up freeing the copynotify state later.[ 1626.839430] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP[ 1626.842828] Modules linked in: nfnetlink_queue nfnetlink_log bluetooth cfg80211 rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd nfs_acl lockd grace nfs_localio ext4 crc16 mbcache jbd2 overlay uinput snd_seq_dummy snd_hrtimer qrtr rfkill vfat fat uvcvideo snd_hda_codec_generic videobuf2_vmalloc videobuf2_memops snd_hda_intel uvc snd_intel_dspcfg videobuf2_v4l2 videobuf2_common snd_hda_codec snd_hda_core videodev snd_hwdep snd_seq mc snd_seq_device snd_pcm snd_timer snd soundcore sg loop auth_rpcgss vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs 8021q garp stp llc mrp nvme ghash_ce e1000e nvme_core sr_mod nvme_keyring nvme_auth cdrom vmwgfx drm_ttm_helper ttm sunrpc dm_mirror dm_region_hash dm_log iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse dm_multipath dm_mod nfnetlink[ 1626.855594] CPU: 2 UID: 0 PID: 199 Comm: kworker/u24:33 Kdump: loaded Tainted: G B W 6.17.0-rc7+ #22 PREEMPT(voluntary)[ 1626.857075] Tainted: [B]=BAD_PAGE, [W]=WARN[ 1626.857573] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024[ 1626.858724] Workqueue: nfsd4 laundromat_main [nfsd][ 1626.859304] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)[ 1626.860010] pc : __list_del_entry_valid_or_report+0x148/0x200[ 1626.860601] lr : __list_del_entry_valid_or_report+0x148/0x200[ 1626.861182] sp : ffff8000881d7a40[ 1626.861521] x29: ffff8000881d7a40 x28: 0000000000000018 x27: ffff0000c2a98200[ 1626.862260] x26: 0000000000000600 x25: 0000000000000000 x24: ffff8000881d7b20[ 1626.862986] x23: ffff0000c2a981e8 x22: 1fffe00012410e7d x21: ffff0000920873e8[ 1626.863701] x20: ffff0000920873e8 x19: ffff000086f22998 x18: 0000000000000000[ 1626.864421] x17: 20747562202c3839 x16: 3932326636383030 x15: 3030666666662065[ 1626.865092] x14: 6220646c756f6873 x13: 0000000000000001 x12: ffff60004fd9e4a3[ 1626.865713] x11: 1fffe0004fd9e4a2 x10: ffff60004fd9e4a2 x9 : dfff800000000000[ 1626.866320] x8 : 00009fffb0261b5e x7 : ffff00027ecf2513 x6 : 0000000000000001[ 1626.866938] x5 : ffff00027ecf2510 x4 : ffff60004fd9e4a3 x3 : 0000000000000000[ 1626.867553] x2 : 0000000000000000 x1 : ffff000096069640 x0 : 000000000000006d[ 1626.868167] Call trace:[ 1626.868382] __list_del_entry_valid_or_report+0x148/0x200 (P)[ 1626.868876] _free_cpntf_state_locked+0xd0/0x268 [nfsd][ 1626.869368] nfs4_laundromat+0x6f8/0x1058 [nfsd][ 1626.869813] laundromat_main+0x24/0x60 [nfsd][ 1626.870231] process_one_work+0x584/0x1050[ 1626.870595] worker_thread+0x4c4/0xc60[ 1626.870893] kthread+0x2f8/0x398[ 1626.871146] ret_from_fork+0x10/0x20[ 1626.871422] Code: aa1303e1 aa1403e3 910e8000 97bc55d7 (d4210000)[ 1626.871892] SMP: stopping secondary CPUs

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40275 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix NULL pointer dereference in snd_usb_mixer_controls_baddIn snd_usb_create_streams(), for UAC version 3 devices, the InterfaceAssociation Descriptor (IAD) is retrieved via usb_ifnum_to_if(). If thiscall fails, a fallback routine attempts to obtain the IAD from the nextinterface and sets a BADD profile. However, snd_usb_mixer_controls_badd()assumes that the IAD retrieved from usb_ifnum_to_if() is always valid,without performing a NULL check. This can lead to a NULL pointerdereference when usb_ifnum_to_if() fails to find the interface descriptor.This patch adds a NULL pointer check after calling usb_ifnum_to_if() insnd_usb_mixer_controls_badd() to prevent the dereference.This issue was discovered by syzkaller, which triggered the bug by sendinga crafted USB device descriptor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40277 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Validate command header size against SVGA_CMD_MAX_DATASIZEThis data originates from userspace and is used in buffer offsetcalculations which could potentially overflow causing an out-of-boundsaccess.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40278 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_ife: initialize struct tc_ife to fix KMSAN kernel-infoleakFix a KMSAN kernel-infoleak detected by the syzbot .[net?] KMSAN: kernel-infoleak in __skb_datagram_iterIn tcf_ife_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.This change silences the KMSAN report and prevents potential informationleaks from the kernel memory.This fix has been tested and validated by syzbot. This patch closes thebug reported at the following syzkaller link and ensures no infoleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix improper check of dentry.stream.valid_sizeWe found an infinite loop bug in the exFAT file system that can lead to aDenial-of-Service (DoS) condition. When a dentry in an exFAT filesystem ismalformed, the following system calls - SYS_openat, SYS_ftruncate, andSYS_pwrite64 - can cause the kernel to hang.Root cause analysis shows that the size validation code in exfat_find()does not check whether dentry.stream.valid_size is negative. As a result,the system calls mentioned above can succeed and eventually trigger the DoSissue.This patch adds a check for negative dentry.stream.valid_size to preventthis vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40288 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devicesPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)triggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The rootcause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,but that `man->bdev` (the backing device pointer within the manager) remainsuninitialized (NULL) on APUs-since APUs lack dedicated VRAM and do not fullyset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts toacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading toa kernel OOPS.1. **amdgpu_cs.c**: Extend the existing bandwidth control check in `amdgpu_cs_get_threshold_for_moves()` to include a check for `ttm_resource_manager_used()`. If the manager is not used (uninitialized `bdev`), return 0 for migration thresholds immediately-skipping VRAM-specific logic that would trigger the NULL dereference.2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info reporting to use a conditional: if the manager is used, return the real VRAM usage; otherwise, return 0. This avoids accessing `man->bdev` when it is NULL.3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function) data write path. Use `ttm_resource_manager_used()` to check validity: if the manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set `fb_usage` to 0 (APUs have no discrete framebuffer to report).This approach is more robust than APU-specific checks because it:- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),- Aligns with TTM's design by using its native helper function,- Preserves correct behavior for discrete GPUs (which have fully initialized `man->bdev` and pass the `ttm_resource_manager_used()` check).v4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Add bounds checking in bit_putcs to fix vmalloc-out-of-boundsAdd bounds checking to prevent writes past framebuffer boundaries whenrendering text near screen edges. Return early if the Y position is off-screenand clip image height to screen boundary. Break from the rendering loop if theX position is off-screen. When clipping image width to fit the screen, updatethe character count to match the clipped width to prevent buffer sizemismatches.Without the character count update, bit_putcs_aligned and bit_putcs_unalignedreceive mismatched parameters where the buffer is allocated for the clippedwidth but cnt reflects the original larger count, causing out-of-bounds writes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40307 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: validate cluster allocation bits of the allocation bitmapsyzbot created an exfat image with cluster bits not set for the allocationbitmap. exfat-fs reads and uses the allocation bitmap without checkingthis. The problem is that if the start cluster of the allocation bitmapis 6, cluster 6 can be allocated when creating a directory with mkdir.exfat zeros out this cluster in exfat_mkdir, which can delete existingentries. This can reallocate the allocated entries. In addition,the allocation bitmap is also zeroed out, so cluster 6 can be reallocated.This patch adds exfat_test_bitmap_range to validate that clusters used forthe allocation bitmap are correctly marked as in-use.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40317 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regmap: slimbus: fix bus_context pointer in regmap init callsCommit 4e65bda8273c ("ASoC: wcd934x: fix error handling inwcd934x_codec_parse_data()") revealed the problem in the slimbus regmap.That commit breaks audio playback, for instance, on sdm845 ThundercommDragonboard 845c board: Unable to handle kernel paging request at virtual address ffff8000847cbad4 ... CPU: 5 UID: 0 PID: 776 Comm: aplay Not tainted 6.18.0-rc1-00028-g7ea30958b305 #11 PREEMPT Hardware name: Thundercomm Dragonboard 845c (DT) ... Call trace: slim_xfer_msg+0x24/0x1ac [slimbus] (P) slim_read+0x48/0x74 [slimbus] regmap_slimbus_read+0x18/0x24 [regmap_slimbus] _regmap_raw_read+0xe8/0x174 _regmap_bus_read+0x44/0x80 _regmap_read+0x60/0xd8 _regmap_update_bits+0xf4/0x140 _regmap_select_page+0xa8/0x124 _regmap_raw_write_impl+0x3b8/0x65c _regmap_bus_raw_write+0x60/0x80 _regmap_write+0x58/0xc0 regmap_write+0x4c/0x80 wcd934x_hw_params+0x494/0x8b8 [snd_soc_wcd934x] snd_soc_dai_hw_params+0x3c/0x7c [snd_soc_core] __soc_pcm_hw_params+0x22c/0x634 [snd_soc_core] dpcm_be_dai_hw_params+0x1d4/0x38c [snd_soc_core] dpcm_fe_dai_hw_params+0x9c/0x17c [snd_soc_core] snd_pcm_hw_params+0x124/0x464 [snd_pcm] snd_pcm_common_ioctl+0x110c/0x1820 [snd_pcm] snd_pcm_ioctl+0x34/0x4c [snd_pcm] __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x104 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xec el0t_64_sync_handler+0xa0/0xf0 el0t_64_sync+0x198/0x19cThe __devm_regmap_init_slimbus() started to be used instead of__regmap_init_slimbus() after the commit mentioned above and turns outthe incorrect bus_context pointer (3rd argument) was used in__devm_regmap_init_slimbus(). It should be just "slimbus" (which is equalto &slimbus->dev). Correct it. The wcd934x codec seems to be the only orthe first user of devm_regmap_init_slimbus() but we should fix it tillthe point where __devm_regmap_init_slimbus() was introduced thereforetwo "Fixes" tags.While at this, also correct the same argument in __regmap_init_slimbus().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Sync pending IRQ work before freeing ring bufferFix a race where irq_work can be queued in bpf_ringbuf_commit()but the ring buffer is freed before the work executes.In the syzbot reproducer, a BPF program attached to sched_switchtriggers bpf_ringbuf_commit(), queuing an irq_work. If the ring bufferis freed before this work executes, the irq_work thread may accessesfreed memory.Calling `irq_work_sync(&rb->work)` ensures that all pending irq_workcomplete before freeing the buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40321 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: fix crash while sending Action Frames in standalone AP ModeCurrently, whenever there is a need to transmit an Action frame,the brcmfmac driver always uses the P2P vif to send the "actframe" IOVAR tofirmware. The P2P interfaces were available when wpa_supplicant is managingthe wlan interface.However, the P2P interfaces are not created/initialized when only hostapdis managing the wlan interface. And if hostapd receives an ANQP Query REQAction frame even from an un-associated STA, the brcmfmac driver triesto use an uninitialized P2P vif pointer for sending the IOVAR to firmware.This NULL pointer dereferencing triggers a driver crash. [ 1417.074538] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [...] [ 1417.075188] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [...] [ 1417.075653] Call trace: [ 1417.075662] brcmf_p2p_send_action_frame+0x23c/0xc58 [brcmfmac] [ 1417.075738] brcmf_cfg80211_mgmt_tx+0x304/0x5c0 [brcmfmac] [ 1417.075810] cfg80211_mlme_mgmt_tx+0x1b0/0x428 [cfg80211] [ 1417.076067] nl80211_tx_mgmt+0x238/0x388 [cfg80211] [ 1417.076281] genl_family_rcv_msg_doit+0xe0/0x158 [ 1417.076302] genl_rcv_msg+0x220/0x2a0 [ 1417.076317] netlink_rcv_skb+0x68/0x140 [ 1417.076330] genl_rcv+0x40/0x60 [ 1417.076343] netlink_unicast+0x330/0x3b8 [ 1417.076357] netlink_sendmsg+0x19c/0x3f8 [ 1417.076370] __sock_sendmsg+0x64/0xc0 [ 1417.076391] ____sys_sendmsg+0x268/0x2a0 [ 1417.076408] ___sys_sendmsg+0xb8/0x118 [ 1417.076427] __sys_sendmsg+0x90/0xf8 [ 1417.076445] __arm64_sys_sendmsg+0x2c/0x40 [ 1417.076465] invoke_syscall+0x50/0x120 [ 1417.076486] el0_svc_common.constprop.0+0x48/0xf0 [ 1417.076506] do_el0_svc+0x24/0x38 [ 1417.076525] el0_svc+0x30/0x100 [ 1417.076548] el0t_64_sync_handler+0x100/0x130 [ 1417.076569] el0t_64_sync+0x190/0x198 [ 1417.076589] Code: f9401e80 aa1603e2 f9403be1 5280e483 (f9400000)Fix this, by always using the vif corresponding to the wdev on which theAction frame Transmission request was initiated by the userspace. This way,even if P2P vif is not available, the IOVAR is sent to firmware on AP vifand the ANQP Query RESP Action frame is transmitted without crashing thedriver.Move init_completion() for "send_af_done" from brcmf_p2p_create_p2pdev()to brcmf_p2p_attach(). Because the former function would not get executedwhen only hostapd is managing wlan interface, and it is not safe to doreinit_completion() later in brcmf_p2p_tx_action_frame(), without any priorinit_completion().And in the brcmf_p2p_tx_action_frame() function, the condition check forP2P Presence response frame is not needed, since the wpa_supplicant isproperly sending the P2P Presense Response frame on the P2P-GO vif insteadof the P2P-Device vif.[Cc stable]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40324 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix crash in nfsd4_read_release()When tracing is enabled, the trace_nfsd_read_done trace pointcrashes during the pynfs read.testNoFh test.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40325 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: wait barrier before returning discard request with REQ_NOWAITraid10_handle_discard should wait barrier before returning a discard biowhich has REQ_NOWAIT. And there is no need to print warning calltraceif a discard bio has REQ_NOWAIT flag. Quality engineer usually checksdmesg and reports error if dmesg has warning/error calltrace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40328 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential UAF in smb2_close_cached_fid()find_or_create_cached_dir() could grab a new reference after kref_put()had seen the refcount drop to zero but before cfid_list_lock is acquiredin smb2_close_cached_fid(), leading to use-after-free.Switch to kref_put_lock() so cfid_release() is called withcfid_list_lock held, closing that gap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40331 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: Prevent TOCTOU out-of-bounds writeFor the following path not holding the sock lock, sctp_diag_dump() -> sctp_for_each_endpoint() -> sctp_ep_dump()make sure not to exceed bounds in case the address list has grownbetween buffer allocation (time-of-check) and write (time-of-use).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Correctly handle Rx checksum offload errorsThe stmmac_rx function would previously set skb->ip_summed toCHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabledand the packet was of a known IP ethertype.However, this logic failed to check if the hardware had actuallyreported a checksum error. The hardware status, indicating a header orpayload checksum failure, was being ignored at this stage. This couldcause corrupt packets to be passed up the network stack as valid.This patch corrects the logic by checking the `csum_none` status flag,which is set when the hardware reports a checksum error. If this flagis set, skb->ip_summed is now correctly set to CHECKSUM_NONE,ensuring the kernel's network stack will perform its own validation andproperly handle the corrupt packet.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40341 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:futex: Don't leak robust_list pointer on exec racesys_get_robust_list() and compat_get_robust_list() use ptrace_may_access()to check if the calling task is allowed to access another task'srobust_list pointer. This check is racy against a concurrent exec() in thetarget process.During exec(), a task may transition from a non-privileged binary to aprivileged one (e.g., setuid binary) and its credentials/memory mappingsmay change. If get_robust_list() performs ptrace_may_access() beforethis transition, it may erroneously allow access to sensitive informationafter the target becomes privileged.A racy access allows an attacker to exploit a window during whichptrace_may_access() passes before a target process transitions to aprivileged state via exec().For example, consider a non-privileged task T that is about to execute asetuid-root binary. An attacker task A calls get_robust_list(T) while Tis still unprivileged. Since ptrace_may_access() checks permissionsbased on current credentials, it succeeds. However, if T begins execimmediately afterwards, it becomes privileged and may change its memorymappings. Because get_robust_list() proceeds to access T->robust_listwithout synchronizing with exec() it may read user-space pointers from anow-privileged process.This violates the intended post-exec access restrictions and couldexpose sensitive memory addresses or be used as a primitive in a largerexploit chain. Consequently, the race can lead to unauthorizeddisclosure of information across privilege boundaries and poses apotential security risk.Take a read lock on signal->exec_update_lock prior to invokingptrace_may_access() and accessing the robust_list/compat_robust_list.This ensures that the target task's exec state remains stable during thecheck, allowing for consistent and synchronized validation ofcredentials.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:arch_topology: Fix incorrect error check in topology_parse_cpu_capacity()Fix incorrect use of PTR_ERR_OR_ZERO() in topology_parse_cpu_capacity()which causes the code to proceed with NULL clock pointers. The currentlogic uses !PTR_ERR_OR_ZERO(cpu_clk) which evaluates to true for bothvalid pointers and NULL, leading to potential NULL pointer dereferencein clk_get_rate().Per include/linux/err.h documentation, PTR_ERR_OR_ZERO(ptr) returns:"The error code within @ptr if it is an error pointer; 0 otherwise."This means PTR_ERR_OR_ZERO() returns 0 for both valid pointers AND NULLpointers. Therefore !PTR_ERR_OR_ZERO(cpu_clk) evaluates to true (proceed)when cpu_clk is either valid or NULL, causing clk_get_rate(NULL) to becalled when of_clk_get() returns NULL.Replace with !IS_ERR_OR_NULL(cpu_clk) which only proceeds for validpointers, preventing potential NULL pointer dereference in clk_get_rate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40347 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: enetc: fix the deadlock of enetc_mdio_lockAfter applying the workaround for err050089, the LS1028A platformexperiences RCU stalls on RT kernel. This issue is caused by therecursive acquisition of the read lock enetc_mdio_lock. Here list someof the call stacks identified under the enetc_poll path that may lead toa deadlock:enetc_poll -> enetc_lock_mdio -> enetc_clean_rx_ring OR napi_complete_done -> napi_gro_receive -> enetc_start_xmit -> enetc_lock_mdio -> enetc_map_tx_buffs -> enetc_unlock_mdio -> enetc_unlock_mdioAfter enetc_poll acquires the read lock, a higher-priority writer attemptsto acquire the lock, causing preemption. The writer detects that aread lock is already held and is scheduled out. However, readers underenetc_poll cannot acquire the read lock again because a writer is alreadywaiting, leading to a thread hang.Currently, the deadlock is avoided by adjusting enetc_lock_mdio to preventrecursive lock acquisition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40355 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sysfs: check visibility before changing group attribute ownershipSince commit 0c17270f9b92 ("net: sysfs: Implement is_visible forphys_(port_id, port_name, switch_id)"), __dev_change_net_namespace() canhit WARN_ON() when trying to change owner of a file that isn't visible.See the trace below: WARNING: CPU: 6 PID: 2938 at net/core/dev.c:12410 __dev_change_net_namespace+0xb89/0xc30 CPU: 6 UID: 0 PID: 2938 Comm: incusd Not tainted 6.17.1-1-mainline #1 PREEMPT(full) 4b783b4a638669fb644857f484487d17cb45ed1f Hardware name: Framework Laptop 13 (AMD Ryzen 7040Series)/FRANMDCP07, BIOS 03.07 02/19/2025 RIP: 0010:__dev_change_net_namespace+0xb89/0xc30 [...] Call Trace: ? if6_seq_show+0x30/0x50 do_setlink.isra.0+0xc7/0x1270 ? __nla_validate_parse+0x5c/0xcc0 ? security_capable+0x94/0x1a0 rtnl_newlink+0x858/0xc20 ? update_curr+0x8e/0x1c0 ? update_entity_lag+0x71/0x80 ? sched_balance_newidle+0x358/0x450 ? psi_task_switch+0x113/0x2a0 ? __pfx_rtnl_newlink+0x10/0x10 rtnetlink_rcv_msg+0x346/0x3e0 ? sched_clock+0x10/0x30 ? __pfx_rtnetlink_rcv_msg+0x10/0x10 netlink_rcv_skb+0x59/0x110 netlink_unicast+0x285/0x3c0 ? __alloc_skb+0xdb/0x1a0 netlink_sendmsg+0x20d/0x430 ____sys_sendmsg+0x39f/0x3d0 ? import_iovec+0x2f/0x40 ___sys_sendmsg+0x99/0xe0 __sys_sendmsg+0x8a/0xf0 do_syscall_64+0x81/0x970 ? __sys_bind+0xe3/0x110 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? sock_alloc_file+0x63/0xc0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? alloc_fd+0x12e/0x190 ? put_unused_fd+0x2a/0x70 ? do_sys_openat2+0xa2/0xe0 ? syscall_exit_work+0x143/0x1b0 ? do_syscall_64+0x244/0x970 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] Fix this by checking is_visible() before trying to touch the attribute.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68171 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Ensure XFD state on signal deliverySean reported [1] the following splat when running KVM tests: WARNING: CPU: 232 PID: 15391 at xfd_validate_state+0x65/0x70 Call Trace: fpu__clear_user_states+0x9c/0x100 arch_do_signal_or_restart+0x142/0x210 exit_to_user_mode_loop+0x55/0x100 do_syscall_64+0x205/0x2c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53Chao further identified [2] a reproducible scenario involving signaldelivery: a non-AMX task is preempted by an AMX-enabled task whichmodifies the XFD MSR.When the non-AMX task resumes and reloads XSTATE with init values,a warning is triggered due to a mismatch between fpstate::xfd and theCPU's current XFD state. fpu__clear_user_states() does not currentlyre-synchronize the XFD state after such preemption.Invoke xfd_update_state() which detects and corrects the mismatch ifthere is a dynamic feature.This also benefits the sigreturn path, as fpu__restore_sig() may callfpu__clear_user_states() when the sigframe is inaccessible.[ dhansen: minor changelog munging ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68173 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ftrace: Fix softlockup in ftrace_module_enableA soft lockup was observed when loading amdgpu module.If a module has a lot of tracable functions, multiple callsto kallsyms_lookup can spend too much time in RCU criticalsection and with disabled preemption, causing kernel panic.This is the same issue that was fixed incommit d0b24b4e91fc ("ftrace: Prevent RCU stall on PREEMPT_VOLUNTARYkernels") and commit 42ea22e754ba ("ftrace: Add cond_resched() toftrace_graph_set_hash()").Fix it the same way by adding cond_resched() in ftrace_module_enable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68174 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: enhance kfd process check in switch partitioncurrent switch partition only check if kfd_processes_table is empty.kfd_prcesses_table entry is deleted in kfd_process_notifier_release, butkfd_process tear down is in kfd_process_wq_release.consider two processes:Process A (workqueue) -> kfd_process_wq_release -> Access kfd_node memberProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw-> kfd_node tear down.Process A and B may trigger a race as shown in dmesg log.This patch is to resolve the race by adding an atomic kfd_process counterkfd_processes_count, it increment as create kfd process, decrement asfinish kfd_process_wq_release.v2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pddsand bug fix. (Philip Yang)[3966658.307702] divide error: 0000 [#1] SMP NOPTI[3966658.350818] i10nm_edac[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu][3966658.362839] nfit[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu][3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00[3966658.380967] x86_pkg_temp_thermal[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800[3966658.391533] FS: 0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000[3966658.391534] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[3966658.391536] PKRU: 55555554[3966658.391536] Call Trace:[3966658.391674] deallocate_sdma_queue+0x38/0xa0 [amdgpu][3966658.391762] process_termination_cpsch+0x1ed/0x480 [amdgpu][3966658.399754] intel_powerclamp[3966658.402831] kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu][3966658.402908] kfd_process_wq_release+0x1a/0x1a0 [amdgpu][3966658.410516] coretemp[3966658.434016] process_one_work+0x1ad/0x380[3966658.434021] worker_thread+0x49/0x310[3966658.438963] kvm_intel[3966658.446041] ? process_one_work+0x380/0x380[3966658.446045] kthread+0x118/0x140[3966658.446047] ? __kthread_bind_mask+0x60/0x60[3966658.446050] ret_from_fork+0x1f/0x30[3966658.446053] Modules linked in: kpatch_20765354(OEK)[3966658.455310] kvm[3966658.464534] mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)[3966658.473462] idxd_mdev[3966658.482306] kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68176 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: cadence: Check for the existence of cdns_pcie::ops before using itcdns_pcie::ops might not be populated by all the Cadence glue drivers. Thisis going to be true for the upcoming Sophgo platform which doesn't set theops.Hence, add a check to prevent NULL pointer dereference.[mani: reworded subject and description]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68185 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencingTheoretically it's an oopsable race, but I don't believe one can manageto hit it on real hardware; might become doable on a KVM, but it stillwon't be easy to attack.Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call ofput_unaligned_be64(), we can put that under ->d_lock and be done with that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68191 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:udp_tunnel: use netdev_warn() instead of netdev_WARN()netdev_WARN() uses WARN/WARN_ON to print a backtrace along withfile and line information. In this case, udp_tunnel_nic_register()returning an error is just a failed operation, not a kernel bug.udp_tunnel_nic_register() can fail due to a memory allocationfailure (kzalloc() or udp_tunnel_nic_alloc()).This is a normal runtime error and not a kernel bug.Replace netdev_WARN() with netdev_warn() accordingly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68192 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: initialize MAC header offset in qmimux_rx_fixupRaw IP packets have no MAC header, leaving skb->mac_header uninitialized.This can trigger kernel panics on ARM64 when xfrm or other subsystemsaccess the offset due to strict alignment checks.Initialize the MAC header to prevent such crashes.This can trigger kernel panics on ARM when running IPsec over theqmimux0 interface.Example trace: Internal error: Oops: 000000009600004f [#1] SMP CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.12.34-gbe78e49cb433 #1 Hardware name: LS1028A RDB Board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : xfrm_input+0xde8/0x1318 lr : xfrm_input+0x61c/0x1318 sp : ffff800080003b20 Call trace: xfrm_input+0xde8/0x1318 xfrm6_rcv+0x38/0x44 xfrm6_esp_rcv+0x48/0xa8 ip6_protocol_deliver_rcu+0x94/0x4b0 ip6_input_finish+0x44/0x70 ip6_input+0x44/0xc0 ipv6_rcv+0x6c/0x114 __netif_receive_skb_one_core+0x5c/0x8c __netif_receive_skb+0x18/0x60 process_backlog+0x78/0x17c __napi_poll+0x38/0x180 net_rx_action+0x168/0x2f0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68201 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: remove two invalid BUG_ON()sThose can be triggered trivially by userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pmdomain: arm: scmi: Fix genpd leak on provider registration failureIf of_genpd_add_provider_onecell() fails during probe, the previouslycreated generic power domains are not removed, leading to a memory leakand potential kernel crash later in genpd_debug_add().Add proper error handling to unwind the initialized domains beforereturning from probe to ensure all resources are correctly released onfailure.Example crash trace observed without this fix: | Unable to handle kernel paging request at virtual address fffffffffffffc70 | CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.0-rc1 #405 PREEMPT | Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform | pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : genpd_debug_add+0x2c/0x160 | lr : genpd_debug_init+0x74/0x98 | Call trace: | genpd_debug_add+0x2c/0x160 (P) | genpd_debug_init+0x74/0x98 | do_one_initcall+0xd0/0x2d8 | do_initcall_level+0xa0/0x140 | do_initcalls+0x60/0xa8 | do_basic_setup+0x28/0x40 | kernel_init_freeable+0xe8/0x170 | kernel_init+0x2c/0x140 | ret_from_fork+0x10/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68206 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_ct: add seqadj extension for natted connectionsSequence adjustment may be required for FTP traffic with PASV/EPSV modes.due to need to re-write packet payload (IP, port) on the ftp controlconnection. This can require changes to the TCP length and expectedseq / ack_seq.The easiest way to reproduce this issue is with PASV mode.Example ruleset:table inet ftp_nat { ct helper ftp_helper { type "ftp" protocol tcp l3proto inet } chain prerouting { type filter hook prerouting priority 0; policy accept; tcp dport 21 ct state new ct helper set "ftp_helper" }}table ip nat { chain prerouting { type nat hook prerouting priority -100; policy accept; tcp dport 21 dnat ip prefix to ip daddr map { 192.168.100.1 : 192.168.13.2/32 } } chain postrouting { type nat hook postrouting priority 100 ; policy accept; tcp sport 21 snat ip prefix to ip saddr map { 192.168.13.2 : 192.168.100.1/32 } }}Note that the ftp helper gets assigned *after* the dnat setup.The inverse (nat after helper assign) is handled by an existingcheck in nf_nat_setup_info() and will not show the problem.Topoloy: +-------------------+ +----------------------------------+ | FTP: 192.168.13.2 | <-> | NAT: 192.168.13.3, 192.168.100.1 | +-------------------+ +----------------------------------+ | +-----------------------+ | Client: 192.168.100.2 | +-----------------------+ftp nat changes do not work as expected in this case:Connected to 192.168.100.1.[..]ftp> epsvEPSV/EPRT on IPv4 off.ftp> ls227 Entering passive mode (192,168,100,1,209,129).421 Service not available, remote server has closed connection.Kernel logs:Missing nfct_seqadj_ext_add() setup callWARNING: CPU: 1 PID: 0 at net/netfilter/nf_conntrack_seqadj.c:41[..] __nf_nat_mangle_tcp_packet+0x100/0x160 [nf_nat] nf_nat_ftp+0x142/0x280 [nf_nat_ftp] help+0x4d1/0x880 [nf_conntrack_ftp] nf_confirm+0x122/0x2e0 [nf_conntrack] nf_hook_slow+0x3c/0xb0 ..Fix this by adding the required extension when a conntrack helper is assignedto a connection that has a nat binding.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68211 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ksm: use range-walk function to jump over holes in scan_get_next_rmap_itemCurrently, scan_get_next_rmap_item() walks every page address in a VMA tolocate mergeable pages. This becomes highly inefficient when scanninglarge virtual memory areas that contain mostly unmapped regions, causingksmd to use large amount of cpu without deduplicating much pages.This patch replaces the per-address lookup with a range walk usingwalk_page_range(). The range walker allows KSM to skip over entireunmapped holes in a VMA, avoiding unnecessary lookups. This problem waspreviously discussed in [1].Consider the following test program which creates a 32 TiB mapping in thevirtual address space but only populates a single page:#include #include #include /* 32 TiB */const size_t size = 32ul * 1024 * 1024 * 1024 * 1024;int main() { char *area = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0); if (area == MAP_FAILED) { perror("mmap() failed\n"); return -1; } /* Populate a single page such that we get an anon_vma. */ *area = 0; /* Enable KSM. */ madvise(area, size, MADV_MERGEABLE); pause(); return 0;}$ ./ksm-sparse &$ echo 1 > /sys/kernel/mm/ksm/run Without this patch ksmd uses 100% of the cpu for a long time (more then 1hour in my test machine) scanning all the 32 TiB virtual address spacethat contain only one mapped page. This makes ksmd essentially deadlockednot able to deduplicate anything of value. With this patch ksmd walksonly the one mapped page and skips the rest of the 32 TiB virtual addressspace, making the scan fast using little cpu.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68214 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:timers: Fix NULL function pointer race in timer_shutdown_sync()There is a race condition between timer_shutdown_sync() and timerexpiration that can lead to hitting a WARN_ON in expire_timers().The issue occurs when timer_shutdown_sync() clears the timer functionto NULL while the timer is still running on another CPU. The racescenario looks like this:CPU0 CPU1 lock_timer_base() expire_timers() base->running_timer = timer; unlock_timer_base() [call_timer_fn enter] mod_timer() ...timer_shutdown_sync()lock_timer_base()// For now, will not detach the timer but only clear its function to NULLif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base() [call_timer_fn exit] lock_timer_base() base->running_timer = NULL; unlock_timer_base() ... // Now timer is pending while its function set to NULL. // next timer trigger expire_timers() WARN_ON_ONCE(!fn) // hit ...lock_timer_base()// Now timer will detachif (base->running_timer != timer) ret = detach_if_pending(timer, base, true);if (shutdown) timer->function = NULL;unlock_timer_base()The problem is that timer_shutdown_sync() clears the timer functionregardless of whether the timer is currently running. This can leave apending timer with a NULL function pointer, which triggers theWARN_ON_ONCE(!fn) check in expire_timers().Fix this by only clearing the timer function when actually detaching thetimer. If the timer is running, leave the function pointer intact, which issafe because the timer will be properly detached when it finishes running.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68219 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix memory leak in smb3_fs_context_parse_param error pathAdd proper cleanup of ctx->source and fc->source to thecifs_parse_mount_err error handler. This ensures that memory allocatedfor the source strings is correctly freed on all error paths, matchingthe cleanup already performed in the success path bysmb3_cleanup_fs_context_contents().Pointers are also set to NULL after freeing to prevent potentialdouble-free issues.This change fixes a memory leak originally detected by syzbot. Theleak occurred when processing Opt_source mount options if an errorhappened after ctx->source and fc->source were successfullyallocated but before the function completed.The specific leak sequence was:1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory3. A subsequent error jumps to cifs_parse_mount_err4. The old error handler freed passwords but not the source strings,causing the memory to leak.This issue was not addressed by commit e8c73eb7db0a ("cifs: client:fix memory leak in smb3_fs_context_parse_param"), which only fixedleaks from repeated fsconfig() calls but not this error path.Patch updated with minor change suggested by kernel test robot

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68227 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Fix proto fallback detection with BPFThe sockmap feature allows bpf syscall from userspace, or basedon bpf sockops, replacing the sk_prot of sockets during protocol stackprocessing with sockmap's custom read/write interfaces.'''tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot'''When the server has MPTCP enabled but the client sends a TCP SYNwithout MPTCP, subflow_syn_recv_sock() performs a fallback on thesubflow, replacing the subflow sk's sk_prot with the native sk_prot.'''subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override()'''Then, this subflow can be normally used by sockmap, which replaces thenative sk_prot with sockmap's custom sk_prot. The issue occurs when theuser executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops().Here, it uses sk->sk_prot to compare with the native sk_prot, but thisis incorrect when sockmap is used, as we may incorrectly setsk->sk_socket->ops.This fix uses the more generic sk_family for the comparison instead.Additionally, this also prevents a WARNING from occurring:result from ./scripts/decode_stacktrace.sh:------------[ cut here ]------------WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \(net/mptcp/protocol.c:4005)Modules linked in:...PKRU: 55555554Call Trace:do_accept (net/socket.c:1989)__sys_accept4 (net/socket.c:2028 net/socket.c:2057)__x64_sys_accept (net/socket.c:2067)x64_sys_call (arch/x86/entry/syscall_64.c:41)do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)RIP: 0033:0x7f87ac92b83d---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68229 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and weattempt to dereference it in tcm_loop_tpg_address_show() we will get asegfault, see below for an example. So, check tl_hba->sh beforedereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop]... Call Trace: configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempool: fix poisoning order>0 pages with HIGHMEMThe kernel test has reported: BUG: unable to handle page fault for address: fffba000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page *pde = 03171067 *pte = 00000000 Oops: Oops: 0002 [#1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE a1d066dfe789f54bc7645c7989957d2bdee593ca Tainted: [T]=RANDSTRUCT Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17) Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56 EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8 DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287 CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690 Call Trace: poison_element (mm/mempool.c:83 mm/mempool.c:102) mempool_init_node (mm/mempool.c:142 mm/mempool.c:226) mempool_init_noprof (mm/mempool.c:250 (discriminator 1)) ? mempool_alloc_pages (mm/mempool.c:640) bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8)) ? mempool_alloc_pages (mm/mempool.c:640) do_one_initcall (init/main.c:1283)Christoph found out this is due to the poisoning code not dealingproperly with CONFIG_HIGHMEM because only the first page is mapped butthen the whole potentially high-order page is accessed.We could give up on HIGHMEM here, but it's straightforward to fix thiswith a loop that's mapping, poisoning or checking and unmappingindividual pages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68239 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:binfmt_misc: restore write access before closing files opened by open_exec()bm_register_write() opens an executable file using open_exec(), whichinternally calls do_open_execat() and denies write access on the file toavoid modification while it is being executed.However, when an error occurs, bm_register_write() closes the file usingfilp_close() directly. This does not restore the write permission, whichmay cause subsequent write operations on the same file to fail.Fix this by calling exe_file_allow_write_access() before filp_close() torestore the write permission properly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68241 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: route: Prevent rt_bind_exception() from rebinding stale fnheThe sit driver's packet transmission path calls: sit_tunnel_xmit() ->update_or_create_fnhe(), which lead to fnhe_remove_oldest() being calledto delete entries exceeding FNHE_RECLAIM_DEPTH+random.The race window is between fnhe_remove_oldest() selecting fnheX fordeletion and the subsequent kfree_rcu(). During this time, theconcurrent path's __mkroute_output() -> find_exception() can fetch thesoon-to-be-deleted fnheX, and rt_bind_exception() then binds it with anew dst using a dst_hold(). When the original fnheX is freed via RCU,the dst reference remains permanently leaked.CPU 0 CPU 1__mkroute_output() find_exception() [fnheX] update_or_create_fnhe() fnhe_remove_oldest() [fnheX] rt_bind_exception() [bind dst] RCU callback [fnheX freed, dst leak]This issue manifests as a device reference count leak and a warning indmesg when unregistering the net device: unregister_netdevice: waiting for sitX to become free. Usage count = NIdo Schimmel provided the simple test validation method [1].The fix clears 'oldest->fnhe_daddr' before calling fnhe_flush_routes().Since rt_bind_exception() checks this field, setting it to zero preventsthe stale fnhe from being reused and bound to a new dst just before itis freed.[1]ip netns add ns1ip -n ns1 link set dev lo upip -n ns1 address add 192.0.2.1/32 dev loip -n ns1 link add name dummy1 up type dummyip -n ns1 route add 192.0.2.2/32 dev dummy1ip -n ns1 link add name gretap1 up arp off type gretap \ local 192.0.2.1 remote 192.0.2.2ip -n ns1 route add 198.51.0.0/16 dev gretap1taskset -c 0 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &taskset -c 2 ip netns exec ns1 mausezahn gretap1 \ -A 198.51.100.1 -B 198.51.0.0/16 -t udp -p 1000 -c 0 -q &sleep 10ip netns pids ns1 | xargs killip netns del ns1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTDOn completion of i915_vma_pin_ww(), a synchronous variant ofdma_fence_work_commit() is called. When pinning a VMA to GGTT addressspace on a Cherry View family processor, or on a Broxton generation SoCwith VTD enabled, i.e., when stop_machine() is then called fromintel_ggtt_bind_vma(), that can potentially lead to lock inversion amongreservation_ww and cpu_hotplug locks.[86.861179] ======================================================[86.861193] WARNING: possible circular locking dependency detected[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G U[86.861226] ------------------------------------------------------[86.861238] i915_module_loa/1432 is trying to acquire lock:[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50[86.861290]but task is already holding lock:[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915][86.862233]which lock already depends on the new lock.[86.862251]the existing dependency chain (in reverse order) is:[86.862265]-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:[86.862292] dma_resv_lockdep+0x19a/0x390[86.862315] do_one_initcall+0x60/0x3f0[86.862334] kernel_init_freeable+0x3cd/0x680[86.862353] kernel_init+0x1b/0x200[86.862369] ret_from_fork+0x47/0x70[86.862383] ret_from_fork_asm+0x1a/0x30[86.862399]-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:[86.862425] dma_resv_lockdep+0x178/0x390[86.862440] do_one_initcall+0x60/0x3f0[86.862454] kernel_init_freeable+0x3cd/0x680[86.862470] kernel_init+0x1b/0x200[86.862482] ret_from_fork+0x47/0x70[86.862495] ret_from_fork_asm+0x1a/0x30[86.862509]-> #3 (&mm->mmap_lock){++++}-{3:3}:[86.862531] down_read_killable+0x46/0x1e0[86.862546] lock_mm_and_find_vma+0xa2/0x280[86.862561] do_user_addr_fault+0x266/0x8e0[86.862578] exc_page_fault+0x8a/0x2f0[86.862593] asm_exc_page_fault+0x27/0x30[86.862607] filldir64+0xeb/0x180[86.862620] kernfs_fop_readdir+0x118/0x480[86.862635] iterate_dir+0xcf/0x2b0[86.862648] __x64_sys_getdents64+0x84/0x140[86.862661] x64_sys_call+0x1058/0x2660[86.862675] do_syscall_64+0x91/0xe90[86.862689] entry_SYSCALL_64_after_hwframe+0x76/0x7e[86.862703]-> #2 (&root->kernfs_rwsem){++++}-{3:3}:[86.862725] down_write+0x3e/0xf0[86.862738] kernfs_add_one+0x30/0x3c0[86.862751] kernfs_create_dir_ns+0x53/0xb0[86.862765] internal_create_group+0x134/0x4c0[86.862779] sysfs_create_group+0x13/0x20[86.862792] topology_add_dev+0x1d/0x30[86.862806] cpuhp_invoke_callback+0x4b5/0x850[86.862822] cpuhp_issue_call+0xbf/0x1f0[86.862836] __cpuhp_setup_state_cpuslocked+0x111/0x320[86.862852] __cpuhp_setup_state+0xb0/0x220[86.862866] topology_sysfs_init+0x30/0x50[86.862879] do_one_initcall+0x60/0x3f0[86.862893] kernel_init_freeable+0x3cd/0x680[86.862908] kernel_init+0x1b/0x200[86.862921] ret_from_fork+0x47/0x70[86.862934] ret_from_fork_asm+0x1a/0x30[86.862947]-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:[86.862969] __mutex_lock+0xaa/0xed0[86.862982] mutex_lock_nested+0x1b/0x30[86.862995] __cpuhp_setup_state_cpuslocked+0x67/0x320[86.863012] __cpuhp_setup_state+0xb0/0x220[86.863026] page_alloc_init_cpuhp+0x2d/0x60[86.863041] mm_core_init+0x22/0x2d0[86.863054] start_kernel+0x576/0xbd0[86.863068] x86_64_start_reservations+0x18/0x30[86.863084] x86_64_start_kernel+0xbf/0x110[86.863098] common_startup_64+0x13e/0x141[86.863114]-> #0 (cpu_hotplug_lock){++++}-{0:0}:[86.863135] __lock_acquire+0x16---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68245 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: netpoll: fix incorrect refcount handling causing incorrect cleanupcommit efa95b01da18 ("netpoll: fix use after free") incorrectlyignored the refcount and prematurely set dev->npinfo to NULL duringnetpoll cleanup, leading to improper behavior and memory leaks.Scenario causing lack of proper cleanup:1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is allocated, and refcnt = 1 - Keep in mind that npinfo is shared among all netpoll instances. In this case, there is just one.2) Another netpoll is also associated with the same NIC and npinfo->refcnt += 1. - Now dev->npinfo->refcnt = 2; - There is just one npinfo associated to the netdev.3) When the first netpolls goes to clean up: - The first cleanup succeeds and clears np->dev->npinfo, ignoring refcnt. - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);` - Set dev->npinfo = NULL, without proper cleanup - No ->ndo_netpoll_cleanup() is either called4) Now the second target tries to clean up - The second cleanup fails because np->dev->npinfo is already NULL. * In this case, ops->ndo_netpoll_cleanup() was never called, and the skb pool is not cleaned as well (for the second netpoll instance) - This leaks npinfo and skbpool skbs, which is clearly reported by kmemleak.Revert commit efa95b01da18 ("netpoll: fix use after free") and addsclarifying comments emphasizing that npinfo cleanup should only happenonce the refcount reaches zero, ensuring stable and correct netpollbehavior.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68249 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: hdm_probe: Fix calling put_device() before device initializationThe early error path in hdm_probe() can jump to err_free_mdev before&mdev->dev has been initialized with device_initialize(). Callingput_device(&mdev->dev) there triggers a device core WARN and ends upinvoking kref_put(&kobj->kref, kobject_release) on an uninitializedkobject.In this path the private struct was only kmalloc'ed and the intendedrelease is effectively kfree(mdev) anyway, so free it directly insteadof calling put_device() on an uninitialized device.This removes the WARNING and fixes the pre-initialization error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68257 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: check device's attached status in compat ioctlsSyzbot identified an issue [1] that crashes kernel, seemingly due tounexistent callback dev->get_valid_routes(). By all means, this shouldnot occur as said callback must always be set toget_zero_valid_routes() in __comedi_device_postconfig().As the crash seems to appear exclusively in i386 kernels, at least,judging from [1] reports, the blame lies with compat versionsof standard IOCTL handlers. Several of them are modified anddo not use comedi_unlocked_ioctl(). While functionality of theseioctls essentially copy their original versions, they do nothave required sanity check for device's attached status. This,in turn, leads to a possibility of calling select IOCTLs on adevice that has not been properly setup, even via COMEDI_DEVCONFIG.Doing so on unconfigured devices means that several crucial stepsare missed, for instance, specifying dev->get_valid_routes()callback.Fix this somewhat crudely by ensuring device's attached status beforeperforming any ioctls, improving logic consistency between modernand compat functions.[1] Syzbot report:BUG: kernel NULL pointer dereference, address: 0000000000000000...CR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0Call Trace: get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline] parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401 do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594 compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline] comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273 __do_compat_sys_ioctl fs/ioctl.c:695 [inline] __se_compat_sys_ioctl fs/ioctl.c:638 [inline] __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638 do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68258 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: multiq3: sanitize config options in multiq3_attach()Syzbot identified an issue [1] in multiq3_attach() that induces atask timeout due to open() or COMEDI_DEVCONFIG ioctl operations,specifically, in the case of multiq3 driver.This problem arose when syzkaller managed to craft weird configurationoptions used to specify the number of channels in encoder subdevice.If a particularly great number is passed to s->n_chan inmultiq3_attach() via it->options[2], then multiple calls tomultiq3_encoder_reset() at the end of driver-specific attach() methodwill be running for minutes, thus blocking tasks and affected devicesas well.While this issue is most likely not too dangerous for real-lifedevices, it still makes sense to sanitize configuration inputs. Enablea sensible limit on the number of encoder chips (4 chips max, eachwith 2 channels) to stop this behaviour from manifesting.[1] Syzbot crash:INFO: task syz.2.19:6067 blocked for more than 143 seconds....Call Trace: context_switch kernel/sched/core.c:5254 [inline] __schedule+0x17c4/0x4d60 kernel/sched/core.c:6862 __schedule_loop kernel/sched/core.c:6944 [inline] schedule+0x165/0x360 kernel/sched/core.c:6959 schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7016 __mutex_lock_common kernel/locking/mutex.c:676 [inline] __mutex_lock+0x7e6/0x1350 kernel/locking/mutex.c:760 comedi_open+0xc0/0x590 drivers/comedi/comedi_fops.c:2868 chrdev_open+0x4cc/0x5e0 fs/char_dev.c:414 do_dentry_open+0x953/0x13f0 fs/open.c:965 vfs_open+0x3b/0x340 fs/open.c:1097...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: add i_data_sem protection in ext4_destroy_inline_data_nolock()Fix a race between inline data destruction and block mapping.The function ext4_destroy_inline_data_nolock() changes the inode datalayout by clearing EXT4_INODE_INLINE_DATA and setting EXT4_INODE_EXTENTS.At the same time, another thread may execute ext4_map_blocks(), whichtests EXT4_INODE_EXTENTS to decide whether to call ext4_ext_map_blocks()or ext4_ind_map_blocks().Without i_data_sem protection, ext4_ind_map_blocks() may receive inodewith EXT4_INODE_EXTENTS flag and triggering assert.kernel BUG at fs/ext4/indirect.c:546!EXT4-fs (loop2): unmounting filesystem.invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTIHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:ext4_ind_map_blocks.cold+0x2b/0x5a fs/ext4/indirect.c:546Call Trace: ext4_map_blocks+0xb9b/0x16f0 fs/ext4/inode.c:681 _ext4_get_block+0x242/0x590 fs/ext4/inode.c:822 ext4_block_write_begin+0x48b/0x12c0 fs/ext4/inode.c:1124 ext4_write_begin+0x598/0xef0 fs/ext4/inode.c:1255 ext4_da_write_begin+0x21e/0x9c0 fs/ext4/inode.c:3000 generic_perform_write+0x259/0x5d0 mm/filemap.c:3846 ext4_buffered_write_iter+0x15b/0x470 fs/ext4/file.c:285 ext4_file_write_iter+0x8e0/0x17f0 fs/ext4/file.c:679 call_write_iter include/linux/fs.h:2271 [inline] do_iter_readv_writev+0x212/0x3c0 fs/read_write.c:735 do_iter_write+0x186/0x710 fs/read_write.c:861 vfs_iter_write+0x70/0xa0 fs/read_write.c:902 iter_file_splice_write+0x73b/0xc90 fs/splice.c:685 do_splice_from fs/splice.c:763 [inline] direct_splice_actor+0x10f/0x170 fs/splice.c:950 splice_direct_to_actor+0x33a/0xa10 fs/splice.c:896 do_splice_direct+0x1a9/0x280 fs/splice.c:1002 do_sendfile+0xb13/0x12c0 fs/read_write.c:1255 __do_sys_sendfile64 fs/read_write.c:1323 [inline] __se_sys_sendfile64 fs/read_write.c:1309 [inline] __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68276 Severity: Moderate CVSS3 score: 5.5

Description: Avahi is a system which facilitates service discovery on a local network via the mDNS/DNS-SD protocol suite. In 0.9-rc2 and earlier, an unprivileged local users can crash avahi-daemon (with wide-area disabled) by creating record browsers with the AVAHI_LOOKUP_USE_WIDE_AREA flag set via D-Bus. This can be done by either callingthe RecordBrowserNew method directly or creating hostname/address/service resolvers/browsers that create those browsers internally themselves.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2025-68282 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: udc: fix use-after-free in usb_gadget_state_workA race condition during gadget teardown can lead to a use-after-freein usb_gadget_state_work(), as reported by KASAN: BUG: KASAN: invalid-access in sysfs_notify+0x2c/0xd0 Workqueue: events usb_gadget_state_workThe fundamental race occurs because a concurrent event (e.g., aninterrupt) can call usb_gadget_set_state() and schedule gadget->workat any time during the cleanup process in usb_del_gadget().Commit 399a45e5237c ("usb: gadget: core: flush gadget workqueue afterdevice removal") attempted to fix this by moving flush_work() to afterdevice_del(). However, this does not fully solve the race, as a newwork item can still be scheduled *after* flush_work() completes butbefore the gadget's memory is freed, leading to the same use-after-free.This patch fixes the race condition robustly by introducing a 'teardown'flag and a 'state_lock' spinlock to the usb_gadget struct. The flag isset during cleanup in usb_del_gadget() *before* calling flush_work() toprevent any new work from being scheduled once cleanup has commenced.The scheduling site, usb_gadget_set_state(), now checks this flag underthe lock before queueing the work, thus safely closing the race window.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68287 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call pathsThis patch addresses a race condition caused by unsynchronizedexecution of multiple call paths invoking `dwc3_remove_requests()`,leading to premature freeing of USB requests and subsequent crashes.Three distinct execution paths interact with `dwc3_remove_requests()`:Path 1:Triggered via `dwc3_gadget_reset_interrupt()` during USB resethandling. The call stack includes:- `dwc3_ep0_reset_state()`- `dwc3_ep0_stall_and_restart()`- `dwc3_ep0_out_start()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 2:Also initiated from `dwc3_gadget_reset_interrupt()`, but through`dwc3_stop_active_transfers()`. The call stack includes:- `dwc3_stop_active_transfers()`- `dwc3_remove_requests()`- `dwc3_gadget_del_and_unmap_request()`Path 3:Occurs independently during `adb root` execution, which triggersUSB function unbind and bind operations. The sequence includes:- `gserial_disconnect()`- `usb_ep_disable()`- `dwc3_gadget_ep_disable()`- `dwc3_remove_requests()` with `-ESHUTDOWN` statusPath 3 operates asynchronously and lacks synchronization with Paths1 and 2. When Path 3 completes, it disables endpoints and frees 'out'requests. If Paths 1 or 2 are still processing these requests,accessing freed memory leads to a crash due to use-after-free conditions.To fix this added check for request completion and skip processingif already completed and added the request status for ep0 while queue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_eem: Fix memory leak in eem_unwrapThe existing code did not handle the failure case of usb_ep_queue in thecommand path, potentially leading to memory leaks.Improve error handling to free all allocated resources on usb_ep_queuefailure. This patch continues to use goto logic for error handling, as theexisting error handling is complex and not easily adaptable to auto-cleanuphelpers.kmemleak results: unreferenced object 0xffffff895a512300 (size 240): backtrace: slab_post_alloc_hook+0xbc/0x3a4 kmem_cache_alloc+0x1b4/0x358 skb_clone+0x90/0xd8 eem_unwrap+0x1cc/0x36c unreferenced object 0xffffff8a157f4000 (size 256): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 dwc3_gadget_ep_alloc_request+0x58/0x11c usb_ep_alloc_request+0x40/0xe4 eem_unwrap+0x204/0x36c unreferenced object 0xffffff8aadbaac00 (size 128): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc __kmalloc+0x64/0x1a8 eem_unwrap+0x218/0x36c unreferenced object 0xffffff89ccef3500 (size 64): backtrace: slab_post_alloc_hook+0xbc/0x3a4 __kmem_cache_alloc_node+0x1b4/0x2dc kmalloc_trace+0x48/0x140 eem_unwrap+0x238/0x36c

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68290 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:most: usb: fix double free on late probe failureThe MOST subsystem has a non-standard registration function which freesthe interface on registration failures and on deregistration.This unsurprisingly leads to bugs in the MOST drivers, and a couple ofrecent changes turned a reference underflow and use-after-free in theUSB driver into several double free and a use-after-free on late probefailures.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68295 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix memory leak in cifs_construct_tcon()When having a multiuser mount with domain= specified and usingcifscreds, cifs_set_cifscreds() will end up setting @ctx->domainname,so it needs to be freed before leaving cifs_construct_tcon().This fixes the following memory leak reported by kmemleak: mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): __kmalloc_node_track_caller_noprof+0x572/0x710 kstrdup+0x3a/0x70 cifs_sb_tlink+0x1209/0x1770 [cifs] cifs_get_fattr+0xe1/0xf50 [cifs] cifs_get_inode_info+0xb5/0x240 [cifs] cifs_revalidate_dentry_attr+0x2d1/0x470 [cifs] cifs_getattr+0x28e/0x450 [cifs] vfs_getattr_nosec+0x126/0x180 vfs_statx+0xf6/0x220 do_statx+0xab/0x110 __x64_sys_statx+0xd5/0x130 do_syscall_64+0xbb/0x380 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68296 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setupProtect vga_switcheroo_client_fb_set() with console lock. Avoids OOBaccess in fbcon_remap_all(). Without holding the console lock the callraces with switching outputs.VGA switcheroo calls fbcon_remap_all() when switching clients. The fbconfunction uses struct fb_info.node, which is set by register_framebuffer().As the fb-helper code currently sets up VGA switcheroo before registeringthe framebuffer, the value of node is -1 and therefore not a legal value.For example, fbcon uses the value within set_con2fb_map() [1] as an indexinto an array.Moving vga_switcheroo_client_fb_set() after register_framebuffer() canresult in VGA switching that does not switch fbcon correctly.Therefore move vga_switcheroo_client_fb_set() under fbcon_fb_registered(),which already holds the console lock. Fbdev calls fbcon_fb_registered()from within register_framebuffer(). Serializes the helper with VGAswitcheroo's call to fbcon_remap_all().Although vga_switcheroo_client_fb_set() takes an instance of struct fb_infoas parameter, it really only needs the contained fbcon state. Moving thecall to fbcon initialization is therefore cleaner than before. Only amdgpu,i915, nouveau and radeon support vga_switcheroo. For all other drivers,this change does nothing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68302 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: sxgbe: fix potential NULL dereference in sxgbe_rx()Currently, when skb is null, the driver prints an error and thendereferences skb on the next line.To fix this, let's add a 'break' after the error message to switchto sxgbe_rx_refill(), which is similar to the approach taken by theother drivers in this particular case, e.g. calxeda with xgmac_rx().Found during a code review.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68303 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: intel: punit_ipc: fix memory corruptionThis passes the address of the pointer "&punit_ipcdev" when the intentwas to pass the pointer itself "punit_ipcdev" (without the ampersand).This means that the: complete(&ipcdev->cmd_complete);in intel_punit_ioc() will write to a wrong memory address corrupting it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:can: kvaser_usb: leaf: Fix potential infinite loop in command parsersThe `kvaser_usb_leaf_wait_cmd()` and `kvaser_usb_leaf_read_bulk_callback`functions contain logic to zero-length commands. These commands are usedto align data to the USB endpoint's wMaxPacketSize boundary.The driver attempts to skip these placeholders by aligning the bufferposition `pos` to the next packet boundary using `round_up()` function.However, if zero-length command is found exactly on a packet boundary(i.e., `pos` is a multiple of wMaxPacketSize, including 0), `round_up`function will return the unchanged value of `pos`. This prevents `pos`to be increased, causing an infinite loop in the parsing logic.This patch fixes this in the function by using `pos + 1` instead.This ensures that even if `pos` is on a boundary, the calculation isbased on `pos + 1`, forcing `round_up()` to always return the nextaligned boundary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Prevents free active keventThe root cause of this issue are:1. When probing the usbnet device, executing usbnet_link_change(dev, 0, 0);put the kevent work in global workqueue. However, the kevent has not yetbeen scheduled when the usbnet device is unregistered. Therefore, executingfree_netdev() results in the "free active object (kevent)" error reportedhere.2. Another factor is that when calling usbnet_disconnect()->unregister_netdev(),if the usbnet device is up, ndo_stop() is executed to cancel the kevent.However, because the device is not up, ndo_stop() is not executed.The solution to this problem is to cancel the kevent before executingfree_netdev().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: accel: bmc150: Fix irq assumption regressionThe code in bmc150-accel-core.c unconditionally callsbmc150_accel_set_interrupt() in the iio_buffer_setup_ops,such as on the runtime PM resume path giving a kernelsplat like this if the device has no interrupts:Unable to handle kernel NULL pointer dereference at virtual address 00000001 when readPC is at bmc150_accel_set_interrupt+0x98/0x194LR is at __pm_runtime_resume+0x5c/0x64(...)Call trace:bmc150_accel_set_interrupt from bmc150_accel_buffer_postenable+0x40/0x108bmc150_accel_buffer_postenable from __iio_update_buffers+0xbe0/0xcbc__iio_update_buffers from enable_store+0x84/0xc8enable_store from kernfs_fop_write_iter+0x154/0x1b4This bug seems to have been in the driver since the beginning,but it only manifests recently, I do not know why.Store the IRQ number in the state struct, as this is a commonpattern in other drivers, then use this to determine if we haveIRQ support or not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68336 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:locking/spinlock/debug: Fix data-race in do_raw_write_lockKCSAN reports:BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lockwrite (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1: do_raw_write_lock+0x120/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkread to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0: do_raw_write_lock+0x88/0x204 _raw_write_lock_irq do_exit call_usermodehelper_exec_async ret_from_forkvalue changed: 0xffffffff -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") hasadressed most of these races, but seems to be not consistent/not complete.>From do_raw_write_lock() only debug_write_lock_after() part has beenconverted to WRITE_ONCE(), but not debug_write_lock_before() part.Do it now.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68337 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corruptedThere's issue when file system corrupted:------------[ cut here ]------------kernel BUG at fs/jbd2/transaction.c:1289!Oops: invalid opcode: 0000 [#1] SMP KASAN PTICPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-nextRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0RSP: 0018:ffff888117aafa30 EFLAGS: 00010202RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0Call Trace: __ext4_journal_get_create_access+0x42/0x170 ext4_getblk+0x319/0x6f0 ext4_bread+0x11/0x100 ext4_append+0x1e6/0x4a0 ext4_init_new_dir+0x145/0x1d0 ext4_mkdir+0x326/0x920 vfs_mkdir+0x45c/0x740 do_mkdirat+0x234/0x2f0 __x64_sys_mkdir+0xd6/0x120 do_syscall_64+0x5f/0xfa0 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe above issue occurs with us in errors=continue mode when accompanied bystorage failures. There have been many inconsistencies in the file systemdata.In the case of file system data inconsistency, for example, if the blockbitmap of a referenced block is not set, it can lead to the situation wherea block being committed is allocated and used again. As a result, thefollowing condition will not be satisfied then trigger BUG_ON. Of course,it is entirely possible to construct a problematic image that can triggerthis BUG_ON through specific operations. In fact, I have constructed suchan image and easily reproduced this issue.Therefore, J_ASSERT() holds true only under ideal conditions, but it maynot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()directly in abnormal situations would cause the system to crash, which isclearly not what we want. So here we directly trigger a JBD abort insteadof immediately invoking BUG_ON.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68345 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: cs35l41: Fix NULL pointer dereference in cs35l41_hda_read_acpi()The acpi_get_first_physical_node() function can return NULL, in whichcase the get_device() function also returns NULL, but this value isthen dereferenced without checking,so add a check to prevent a crash.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68346 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: dice: fix buffer overflow in detect_stream_formats()The function detect_stream_formats() reads the stream_count value directlyfrom a FireWire device without validating it. This can lead toout-of-bounds writes when a malicious device provides a stream_count valuegreater than MAX_STREAMS.Fix by applying the same validation to both TX and RX stream counts indetect_stream_formats().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68349 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Clear NFS_INO_LAYOUTCOMMIT in pnfs_mark_layout_stateid_invalidFixes a crash when layout is null during this call stack:write_inode -> nfs4_write_inode -> pnfs_layoutcommit_inodepnfs_set_layoutcommit relies on the lseg refcount to keep the layoutaround. Need to clear NFS_INO_LAYOUTCOMMIT otherwise we might attemptto reference a null layout.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Protect regulator_supply_alias_list with regulator_list_mutexregulator_supply_alias_list was accessed without any locking inregulator_supply_alias(), regulator_register_supply_alias(), andregulator_unregister_supply_alias(). Concurrent registration,unregistration and lookups can race, leading to:1 use-after-free if an alias entry is removed while being read,2 duplicate entries when two threads register the same alias,3 inconsistent alias mappings observed by consumers.Protect all traversals, insertions and deletions onregulator_supply_alias_list with the existing regulator_list_mutex.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68358 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix racy bitfield write in btrfs_clear_space_info_full()From the memory-barriers.txt document regarding memory barrier orderingguarantees: (*) These guarantees do not apply to bitfields, because compilers often generate code to modify these using non-atomic read-modify-write sequences. Do not attempt to use bitfields to synchronize parallel algorithms. (*) Even in cases where bitfields are protected by locks, all fields in a given bitfield must be protected by one lock. If two fields in a given bitfield are protected by different locks, the compiler's non-atomic read-modify-write sequences can cause an update to one field to corrupt the value of an adjacent field.btrfs_space_info has a bitfield sharing an underlying word consisting ofthe fields full, chunk_alloc, and flush:struct btrfs_space_info { struct btrfs_fs_info * fs_info; /* 0 8 */ struct btrfs_space_info * parent; /* 8 8 */ ... int clamp; /* 172 4 */ unsigned int full:1; /* 176: 0 4 */ unsigned int chunk_alloc:1; /* 176: 1 4 */ unsigned int flush:1; /* 176: 2 4 */ ...Therefore, to be safe from parallel read-modify-writes losing a write toone of the bitfield members protected by a lock, all writes to all thebitfields must use the lock. They almost universally do, except forbtrfs_clear_space_info_full() which iterates over the space_infos andwrites out found->full = 0 without a lock.Imagine that we have one thread completing a transaction in which wefinished deleting a block_group and are thus callingbtrfs_clear_space_info_full() while simultaneously the data reclaimticket infrastructure is running do_async_reclaim_data_space(): T1 T2btrfs_commit_transaction btrfs_clear_space_info_full data_sinfo->full = 0 READ: full:0, chunk_alloc:0, flush:1 do_async_reclaim_data_space(data_sinfo) spin_lock(&space_info->lock); if(list_empty(tickets)) space_info->flush = 0; READ: full: 0, chunk_alloc:0, flush:1 MOD/WRITE: full: 0, chunk_alloc:0, flush:0 spin_unlock(&space_info->lock); return; MOD/WRITE: full:0, chunk_alloc:0, flush:1and now data_sinfo->flush is 1 but the reclaim worker has exited. Thisbreaks the invariant that flush is 0 iff there is no work queued orrunning. Once this invariant is violated, future allocations that gointo __reserve_bytes() will add tickets to space_info->tickets but willsee space_info->flush is set to 1 and not queue the work. After this,they will block forever on the resulting ticket, as it is now impossibleto kick the worker again.I also confirmed by looking at the assembly of the affected kernel thatit is doing RMW operations. For example, to set the flush (3rd) bit to 0,the assembly is: andb $0xfb,0x60(%rbx)and similarly for setting the full (1st) bit to 0: andb $0xfe,-0x20(%rax)So I think this is really a bug on practical systems. I have observeda number of systems in this exact state, but am currently unable toreproduce it.Rather than leaving this footgun lying around for the future, takeadvantage of the fact that there is room in the struct anyway, and thatit is already quite large and simply change the three bitfield members tobools. This avoids writes to space_info->full having any effect on---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68362 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: rtl8187: Fix potential buffer underflow in rtl8187_rx_cb()The rtl8187_rx_cb() calculates the rx descriptor header addressby subtracting its size from the skb tail pointer.However, it does not validate if the received packet(skb->len from urb->actual_length) is large enough to contain thisheader.If a truncated packet is received, this will lead to a bufferunderflow, reading memory before the start of the skb data area,and causing a kernel panic.Add length checks for both rtl8187 and rtl8187b descriptor headersbefore attempting to access them, dropping the packet cleanly if thecheck fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68363 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Check skb->transport_header is set in bpf_skb_check_mtuThe bpf_skb_check_mtu helper needs to use skb->transport_header whenthe BPF_MTU_CHK_SEGS flag is used: bpf_skb_check_mtu(skb, ifindex, &mtu_len, 0, BPF_MTU_CHK_SEGS)The transport_header is not always set. There is a WARN_ON_ONCEreport when CONFIG_DEBUG_NET is enabled + skb->gso_size is set +bpf_prog_test_run is used:WARNING: CPU: 1 PID: 2216 at ./include/linux/skbuff.h:3071 skb_gso_validate_network_len bpf_skb_check_mtu bpf_prog_3920e25740a41171_tc_chk_segs_flag # A test in the next patch bpf_test_run bpf_prog_test_run_skbFor a normal ingress skb (not test_run), skb_reset_transport_headeris performed but there is plan to avoid setting it as described incommit 2170a1f09148 ("net: no longer reset transport_header in __netif_receive_skb_core()").This patch fixes the bpf helper by checkingskb_transport_header_was_set(). The check is done just beforeskb->transport_header is used, to avoid breaking the existing bpf prog.The WARN_ON_ONCE is limited to bpf_prog_test_run, so targeting bpf-next.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68364 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: relax BUG() to ocfs2_error() in __ocfs2_move_extent()In '__ocfs2_move_extent()', relax 'BUG()' to 'ocfs2_error()' justto avoid crashing the whole kernel due to a filesystem corruption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68366 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config unlock in nbd_genl_connectThere is one use-after-free warning when running NBD_CMD_CONNECT andNBD_CLEAR_SOCK:nbd_genl_connect nbd_alloc_and_init_config // config_refs=1 nbd_start_device // config_refs=2 set NBD_RT_HAS_CONFIG_REF open nbd // config_refs=3 recv_work done // config_refs=2 NBD_CLEAR_SOCK // config_refs=1 close nbd // config_refs=0 refcount_inc -> uaf------------[ cut here ]------------refcount_t: addition on 0; use-after-free.WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcount_warn_saturate+0x12e/0x290 nbd_genl_connect+0x16d0/0x1ab0 genl_family_rcv_msg_doit+0x1f3/0x310 genl_rcv_msg+0x44a/0x790The issue can be easily reproduced by adding a small delay beforerefcount_inc(&nbd->config_refs) in nbd_genl_connect(): mutex_unlock(&nbd->config_lock); if (!ret) { set_bit(NBD_RT_HAS_CONFIG_REF, &config->runtime_flags);+ printk("before sleep\n");+ mdelay(5 * 1000);+ printk("after sleep\n"); refcount_inc(&nbd->config_refs); nbd_connect_reply(info, nbd->index); }

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68367 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:macintosh/mac_hid: fix race condition in mac_hid_toggle_emumouseThe following warning appears when running syzkaller, and this issue alsoexists in the mainline code. ------------[ cut here ]------------ list_add double add: new=ffffffffa57eee28, prev=ffffffffa57eee28, next=ffffffffa5e63100. WARNING: CPU: 0 PID: 1491 at lib/list_debug.c:35 __list_add_valid_or_report+0xf7/0x130 Modules linked in: CPU: 0 PID: 1491 Comm: syz.1.28 Not tainted 6.6.0+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__list_add_valid_or_report+0xf7/0x130 RSP: 0018:ff1100010dfb7b78 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffffffffa57eee18 RCX: ffffffff97fc9817 RDX: 0000000000040000 RSI: ffa0000002383000 RDI: 0000000000000001 RBP: ffffffffa57eee28 R08: 0000000000000001 R09: ffe21c0021bf6f2c R10: 0000000000000001 R11: 6464615f7473696c R12: ffffffffa5e63100 R13: ffffffffa57eee28 R14: ffffffffa57eee28 R15: ff1100010dfb7d48 FS: 00007fb14398b640(0000) GS:ff11000119600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000010d096005 CR4: 0000000000773ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 80000000 Call Trace: input_register_handler+0xb3/0x210 mac_hid_start_emulation+0x1c5/0x290 mac_hid_toggle_emumouse+0x20a/0x240 proc_sys_call_handler+0x4c2/0x6e0 new_sync_write+0x1b1/0x2d0 vfs_write+0x709/0x950 ksys_write+0x12a/0x250 do_syscall_64+0x5a/0x110 entry_SYSCALL_64_after_hwframe+0x78/0xe2The WARNING occurs when two processes concurrently write to the mac-hidemulation sysctl, causing a race condition in mac_hid_toggle_emumouse().Both processes read old_val=0, then both try to register the input handler,leading to a double list_add of the same handler. CPU0 CPU1 ------------------------- ------------------------- vfs_write() //write 1 vfs_write() //write 1 proc_sys_write() proc_sys_write() mac_hid_toggle_emumouse() mac_hid_toggle_emumouse() old_val = *valp // old_val=0 old_val = *valp // old_val=0 mutex_lock_killable() proc_dointvec() // *valp=1 mac_hid_start_emulation() input_register_handler() mutex_unlock() mutex_lock_killable() proc_dointvec() mac_hid_start_emulation() input_register_handler() //Trigger Warning mutex_unlock()Fix this by moving the old_val read inside the mutex lock region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68372 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nbd: defer config put in recv_workThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK andNBD_CMD_RECONFIGURE: nbd_genl_connect // conf_ref=2 (connect and recv_work A) nbd_open // conf_ref=3 recv_work A done // conf_ref=2 NBD_CLEAR_SOCK // conf_ref=1 nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B) close nbd // conf_ref=1 recv_work B config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFOr only running NBD_CLEAR_SOCK: nbd_genl_connect // conf_ref=2 nbd_open // conf_ref=3 NBD_CLEAR_SOCK // conf_ref=2 close nbd nbd_release config_put // conf_ref=1 recv_work config_put // conf_ref=0 atomic_dec(&config->recv_threads); -> UAFCommit 87aac3a80af5 ("nbd: call nbd_config_put() before notifying thewaiter") moved nbd_config_put() to run before waking up the waiter inrecv_work, in order to ensure that nbd_start_device_ioctl() would notbe woken up while nbd->task_recv was still uncleared.However, in nbd_start_device_ioctl(), after being woken up it explicitlycalls flush_workqueue() to make sure all current works are finished.Therefore, there is no need to move the config put ahead of the wakeup.Move nbd_config_put() to the end of recv_work, so that the reference isheld for the whole lifetime of the worker thread. This makes sure theconfig cannot be freed while recv_work is still running, even if clear+ reconfigure interleave.In addition, we don't need to worry about recv_work dropping the lastnbd_put (which causes deadlock):path A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=1 (trigger recv_work) open nbd // nbd_refs=2 NBD_CLEAR_SOCK close nbd nbd_release nbd_disconnect_and_put flush_workqueue // recv_work done nbd_config_put nbd_put // nbd_refs=1 nbd_put // nbd_refs=0 queue_workpath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT): connect // nbd_refs=2 (trigger recv_work) open nbd // nbd_refs=3 NBD_CLEAR_SOCK // conf_refs=2 close nbd nbd_release nbd_config_put // conf_refs=1 nbd_put // nbd_refs=2 recv_work done // conf_refs=0, nbd_refs=1 rmmod // nbd_refs=0Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbd_config_put")

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68379 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix null deref on srq->rq.queue after resize failureA NULL pointer dereference can occur in rxe_srq_chk_attr() whenibv_modify_srq() is invoked twice in succession under certain errorconditions. The first call may fail in rxe_queue_resize(), which leadsrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call thentriggers a crash (null deref) when accessingsrq->rq.queue->buf->index_mask.Call Trace:rxe_modify_srq+0x170/0x480 [rdma_rxe]? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]ib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]? tryinc_node_nr_active+0xe6/0x150? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]ib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]ib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]? __pfx___raw_spin_lock_irqsave+0x10/0x10? __pfx_do_vfs_ioctl+0x10/0x10? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10ib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]__x64_sys_ioctl+0x138/0x1c0do_syscall_64+0x82/0x250? fdget_pos+0x58/0x4c0? ksys_write+0xf3/0x1c0? __pfx_ksys_write+0x10/0x10? do_syscall_64+0xc8/0x250? __pfx_vm_mmap_pgoff+0x10/0x10? fget+0x173/0x230? fput+0x2a/0x80? ksys_mmap_pgoff+0x224/0x4c0? do_syscall_64+0xc8/0x250? do_user_addr_fault+0x37b/0xfe0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0? clear_bhb_loop+0x50/0xa0entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68724 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: asymmetric_keys - prevent overflow in asymmetric_key_generate_idUse check_add_overflow() to guard against potential integer overflowswhen adding the binary blob lengths and the size of an asymmetric_key_idstructure and return ERR_PTR(-EOVERFLOW) accordingly. This prevents apossible buffer overflow when copying data from potentially maliciousX.509 certificate fields that can be arbitrarily large, such as ASN.1INTEGER serial numbers, issuer names, etc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68725 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Do not let BPF test infra emit invalid GSO types to stackYinhao et al. reported that their fuzzer tool was able to trigger askb_warn_bad_offload() from netif_skb_features() -> gso_features_check().When a BPF program - triggered via BPF test infra - pushes the packetto the loopback device via bpf_clone_redirect() then mentioned offloadwarning can be seen. GSO-related features are then rightfully disabled.We get into this situation due to convert___skb_to_skb() settinggso_segs and gso_size but not gso_type. Technically, it makes sensethat this warning triggers since the GSO properties are malformed dueto the gso_type. Potentially, the gso_type could be marked non-trustworthythrough setting it at least to SKB_GSO_DODGY without any other specificassumptions, but that also feels wrong given we should not go furtherinto the GSO engine in the first place.The checks were added in 121d57af308d ("gso: validate gso_type in GSOhandlers") because there were malicious (syzbot) senders that combinea protocol with a non-matching gso_type. If we would want to drop suchpackets, gso_features_check() currently only returns feature flags vianetif_skb_features(), so one location for potentially dropping such skbscould be validate_xmit_unreadable_skb(), but then otoh it would bean additional check in the fast-path for a very corner case. Givenbpf_clone_redirect() is the only place where BPF test infra could emitsuch packets, lets reject them right there.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68733 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smack: fix bug: unprivileged task can create labelsIf an unprivileged task is allowed to relabel itself(/smack/relabel-self is not empty),it can freely create new labels by writing theirnames into own /proc/PID/attr/smack/currentThis occurs because do_setattr() importsthe provided label in advance,before checking "relabel-self" list.This change ensures that the "relabel-self" listis checked before importing the label.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68740 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ima: Handle error code returned by ima_filter_rule_match()In ima_match_rules(), if ima_filter_rule_match() returns -ENOENT due tothe rule being NULL, the function incorrectly skips the 'if (!rc)' checkand sets 'result = true'. The LSM rule is considered a match, causingextra files to be measured by IMA.This issue can be reproduced in the following scenario:After unloading the SELinux policy module via 'semodule -d', if an IMAmeasurement is triggered before ima_lsm_rules is updated,in ima_match_rules(), the first call to ima_filter_rule_match() returns-ESTALE. This causes the code to enter the 'if (rc == -ESTALE &&!rule_reinitialized)' block, perform ima_lsm_copy_rule() and retry. Inima_lsm_copy_rule(), since the SELinux module has been removed, the rulebecomes NULL, and the second call to ima_filter_rule_match() returns-ENOENT. This bypasses the 'if (!rc)' check and results in a false match.Call trace: selinux_audit_rule_match+0x310/0x3b8 security_audit_rule_match+0x60/0xa0 ima_match_rules+0x2e4/0x4a0 ima_match_policy+0x9c/0x1e8 ima_get_action+0x48/0x60 process_measurement+0xf8/0xa98 ima_bprm_check+0x98/0xd8 security_bprm_check+0x5c/0x78 search_binary_handler+0x6c/0x318 exec_binprm+0x58/0x1b8 bprm_execve+0xb8/0x130 do_execveat_common.isra.0+0x1a8/0x258 __arm64_sys_execve+0x48/0x68 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x44/0x200 el0t_64_sync_handler+0x100/0x130 el0t_64_sync+0x3c8/0x3d0Fix this by changing 'if (!rc)' to 'if (rc <= 0)' to ensure that errorcodes like -ENOENT do not bypass the check and accidentally result in asuccessful match.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68757 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vgem-fence: Fix potential deadlock on releaseA timer that expires a vgem fence automatically in 10 seconds is nowreleased with timer_delete_sync() from fence->ops.release() called on lastdma_fence_put(). In some scenarios, it can run in IRQ context, which isnot safe unless TIMER_IRQSAFE is used. One potentially risky scenario wasdemonstrated in Intel DRM CI trybot, BAT run on machine bat-adlp-6, whileworking on new IGT subtests syncobj_timeline@stress-* as user spacereplacements of some problematic test cases of a dma-fence-chain selftest[1].[117.004338] ================================[117.004340] WARNING: inconsistent lock state[117.004342] 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 Tainted: G S U[117.004346] --------------------------------[117.004347] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.[117.004349] swapper/0/0 [HC1[1]:SC1[1]:HE0:SE0] takes:[117.004352] ffff888138f86aa8 ((&fence->timer)){?.-.}-{0:0}, at: __timer_delete_sync+0x4b/0x190[117.004361] {HARDIRQ-ON-W} state was registered at:[117.004363] lock_acquire+0xc4/0x2e0[117.004366] call_timer_fn+0x80/0x2a0[117.004368] __run_timers+0x231/0x310[117.004370] run_timer_softirq+0x76/0xe0[117.004372] handle_softirqs+0xd4/0x4d0[117.004375] __irq_exit_rcu+0x13f/0x160[117.004377] irq_exit_rcu+0xe/0x20[117.004379] sysvec_apic_timer_interrupt+0xa0/0xc0[117.004382] asm_sysvec_apic_timer_interrupt+0x1b/0x20[117.004385] cpuidle_enter_state+0x12b/0x8a0[117.004388] cpuidle_enter+0x2e/0x50[117.004393] call_cpuidle+0x22/0x60[117.004395] do_idle+0x1fd/0x260[117.004398] cpu_startup_entry+0x29/0x30[117.004401] start_secondary+0x12d/0x160[117.004404] common_startup_64+0x13e/0x141[117.004407] irq event stamp: 2282669[117.004409] hardirqs last enabled at (2282668): [] _raw_spin_unlock_irqrestore+0x51/0x80[117.004414] hardirqs last disabled at (2282669): [] sysvec_irq_work+0x11/0xc0[117.004419] softirqs last enabled at (2254702): [] __do_softirq+0x10/0x18[117.004423] softirqs last disabled at (2254725): [] __irq_exit_rcu+0x13f/0x160[117.004426]other info that might help us debug this:[117.004429] Possible unsafe locking scenario:[117.004432] CPU0[117.004433] ----[117.004434] lock((&fence->timer));[117.004436] [117.004438] lock((&fence->timer));[117.004440] *** DEADLOCK ***[117.004443] 1 lock held by swapper/0/0:[117.004445] #0: ffffc90000003d50 ((&fence->timer)){?.-.}-{0:0}, at: call_timer_fn+0x7a/0x2a0[117.004450]stack backtrace:[117.004453] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G S U 6.17.0-rc7-CI_DRM_17270-g7644974e648c+ #1 PREEMPT(voluntary)[117.004455] Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER[117.004455] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023[117.004456] Call Trace:[117.004456] [117.004457] dump_stack_lvl+0x91/0xf0[117.004460] dump_stack+0x10/0x20[117.004461] print_usage_bug.part.0+0x260/0x360[117.004463] mark_lock+0x76e/0x9c0[117.004465] ? register_lock_class+0x48/0x4a0[117.004467] __lock_acquire+0xbc3/0x2860[117.004469] lock_acquire+0xc4/0x2e0[117.004470] ? __timer_delete_sync+0x4b/0x190[117.004472] ? __timer_delete_sync+0x4b/0x190[117.004473] __timer_delete_sync+0x68/0x190[117.004474] ? __timer_delete_sync+0x4b/0x190[117.004475] timer_delete_sync+0x10/0x20[117.004476] vgem_fence_release+0x19/0x30 [vgem][117.004478] dma_fence_release+0xc1/0x3b0[117.004480] ? dma_fence_release+0xa1/0x3b0[117.004481] dma_fence_chain_release+0xe7/0x130[117.004483] dma_fence_release+0xc1/0x3b0[117.004484] ? _raw_spin_unlock_irqrestore+0x27/0x80[117.004485] dma_fence_chain_irq_work+0x59/0x80[117.004487] irq_work_single+0x75/0xa0[117.004490] irq_work_r---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68759 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtl818x: Fix potential memory leaks in rtl8180_init_rx_ring()In rtl8180_init_rx_ring(), memory is allocated for skb packets and DMAallocations in a loop. When an allocation fails, the previouslysuccessful allocations are not freed on exit.Fix that by jumping to err_free_rings label on error, which callsrtl8180_free_rx_ring() to free the allocations. Remove the free ofrx_ring in rtl8180_init_rx_ring() error path, and set the freedpriv->rx_buf entry to null, to avoid double free.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68765 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mt76: mt7615: Fix memory leak in mt7615_mcu_wtbl_sta_add()In mt7615_mcu_wtbl_sta_add(), an skb sskb is allocated. If thesubsequent call to mt76_connac_mcu_alloc_wtbl_req() fails, the functionreturns an error without freeing sskb, leading to a memory leak.Fix this by calling dev_kfree_skb() on sskb in the error handling pathto ensure it is properly released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68767 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: Verify inode mode when loading from disksyzbot is reporting that S_IFMT bits of inode->i_mode can become bogus whenthe S_IFMT bits of the 16bits "mode" field loaded from disk are corrupted.According to [1], the permissions field was treated as reserved in Mac OS8 and 9. According to [2], the reserved field was explicitly initializedwith 0, and that field must remain 0 as long as reserved. Therefore, whenthe "mode" field is not 0 (i.e. no longer reserved), the file must beS_IFDIR if dir == 1, and the file must be one of S_IFREG/S_IFLNK/S_IFCHR/S_IFBLK/S_IFIFO/S_IFSOCK if dir == 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68769 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix return value of f2fs_recover_fsync_data()With below scripts, it will trigger panic in f2fs:mkfs.f2fs -f /dev/vddmount /dev/vdd /mnt/f2fstouch /mnt/f2fs/foosyncecho 111 >> /mnt/f2fs/foof2fs_io fsync /mnt/f2fs/foof2fs_io shutdown 2 /mnt/f2fsumount /mnt/f2fsmount -o ro,norecovery /dev/vdd /mnt/f2fsormount -o ro,disable_roll_forward /dev/vdd /mnt/f2fsF2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 0F2FS-fs (vdd): Mounted with checkpoint version = 7f5c361fF2FS-fs (vdd): Stopped filesystem due to reason: 0F2FS-fs (vdd): f2fs_recover_fsync_data: recovery fsync data, check_only: 1Filesystem f2fs get_tree() didn't set fc->root, returned 1------------[ cut here ]------------kernel BUG at fs/super.c:1761!Oops: invalid opcode: 0000 [#1] SMP PTICPU: 3 UID: 0 PID: 722 Comm: mount Not tainted 6.18.0-rc2+ #721 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014RIP: 0010:vfs_get_tree.cold+0x18/0x1aCall Trace: fc_mount+0x13/0xa0 path_mount+0x34e/0xc50 __x64_sys_mount+0x121/0x150 do_syscall_64+0x84/0x800 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7fa6cc126cfeThe root cause is we missed to handle error number returned fromf2fs_recover_fsync_data() when mounting image w/ ro,norecovery orro,disable_roll_forward mount option, result in returning a positiveerror number to vfs_get_tree(), fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68771 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix kernel BUG in ocfs2_find_victim_chainsyzbot reported a kernel BUG in ocfs2_find_victim_chain() because the`cl_next_free_rec` field of the allocation chain list (next free slot inthe chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec)condition in ocfs2_find_victim_chain() and panicking the kernel.To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(),just before calling ocfs2_find_victim_chain(), the code block in it beingexecuted when either of the following conditions is true:1. `cl_next_free_rec` is equal to 0, indicating that there are no freechains in the allocation chain list2. `cl_next_free_rec` is greater than `cl_count` (the total number ofchains in the allocation chain list)Either of them being true is indicative of the fact that there are nochains left for usage.This is addressed using ocfs2_error(), which printsthe error log for debugging purposes, rather than panicking the kernel.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68780 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: only set free_cpus for online runqueuesCommit 16b269436b72 ("sched/deadline: Modify cpudl::free_cpusto reflect rd->online") introduced the cpudl_set/clear_freecpufunctions to allow the cpu_dl::free_cpus mask to be manipulatedby the deadline scheduler class rq_on/offline callbacks so themask would also reflect this state.Commit 9659e1eeee28 ("sched/deadline: Remove cpu_active_maskfrom cpudl_find()") removed the check of the cpu_active_mask tosave some processing on the premise that the cpudl::free_cpusmask already reflected the runqueue online state.Unfortunately, there are cases where it is possible for thecpudl_clear function to set the free_cpus bit for a CPU when thedeadline runqueue is offline. When this occurs while a CPU isconnected to the default root domain the flag may retain the badstate after the CPU has been unplugged. Later, a different CPUthat is transitioning through the default root domain may push adeadline task to the powered down CPU when cpudl_find sees itsfree_cpus bit is set. If this happens the task will not have theopportunity to run.One example is outlined here:https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.comAnother occurs when the last deadline task is migrated from aCPU that has an offlined runqueue. The dequeue_task member ofthe deadline scheduler class will eventually call cpudl_clearand set the free_cpus bit for the CPU.This commit modifies the cpudl_clear function to be aware of theonline state of the deadline runqueue so that the free_cpus maskcan be updated appropriately.It is no longer necessary to manage the mask outside of thecpudl_set/clear functions so the cpudl_set/clear_freecpufunctions are removed. In addition, since the free_cpus mask isnow only updated under the cpudl lock the code was changed touse the non-atomic __cpumask functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68782 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: Reset t_task_cdb pointer in error caseIf allocation of cmd->t_task_cdb fails, it remains NULL but is laterdereferenced in the 'err' path.In case of error, reset NULL t_task_cdb value to point at the defaultfixed-size buffer.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68783 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-mixer: us16x08: validate meter packet indicesget_meter_levels_from_urb() parses the 64-byte meter packets sent bythe device and fills the per-channel arrays meter_level[],comp_level[] and master_level[] in struct snd_us16x08_meter_store.Currently the function derives the channel index directly from themeter packet (MUB2(meter_urb, s) - 1) and uses it to index thosearrays without validating the range. If the packet contains anegative or out-of-range channel number, the driver may write pastthe end of these arrays.Introduce a local channel variable and validate it before updating thearrays. We reject negative indices, limit meter_level[] andcomp_level[] to SND_US16X08_MAX_CHANNELS, and guard master_level[]updates with ARRAY_SIZE(master_level).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix memory leak in nr_sendmsg()syzbot reported a memory leak [1].When function sock_alloc_send_skb() return NULL in nr_output(), theoriginal skb is not freed, which was allocated in nr_sendmsg(). Fix thisby freeing it before return.[1]BUG: memory leakunreferenced object 0xffff888129f35500 (size 240): comm "syz.0.17", pid 6119, jiffies 4294944652 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 10 52 28 81 88 ff ff ..........R(.... backtrace (crc 1456a3e4): kmemleak_alloc_recursive include/linux/kmemleak.h:44 [inline] slab_post_alloc_hook mm/slub.c:4983 [inline] slab_alloc_node mm/slub.c:5288 [inline] kmem_cache_alloc_node_noprof+0x36f/0x5e0 mm/slub.c:5340 __alloc_skb+0x203/0x240 net/core/skbuff.c:660 alloc_skb include/linux/skbuff.h:1383 [inline] alloc_skb_with_frags+0x69/0x3f0 net/core/skbuff.c:6671 sock_alloc_send_pskb+0x379/0x3e0 net/core/sock.c:2965 sock_alloc_send_skb include/net/sock.h:1859 [inline] nr_sendmsg+0x287/0x450 net/netrom/af_netrom.c:1105 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] sock_write_iter+0x293/0x2a0 net/socket.c:1195 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x45d/0x710 fs/read_write.c:686 ksys_write+0x143/0x170 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xa4/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68796 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating zero-sized extent in extent cacheAs syzbot reported:F2FS-fs (loop0): __update_extent_tree_range: extent len is zero, type: 0, extent [0, 0, 0], age [0, 0]------------[ cut here ]------------kernel BUG at fs/f2fs/extent_cache.c:678!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 0 UID: 0 PID: 5336 Comm: syz.0.0 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__update_extent_tree_range+0x13bc/0x1500 fs/f2fs/extent_cache.c:678Call Trace: f2fs_update_read_extent_cache_range+0x192/0x3e0 fs/f2fs/extent_cache.c:1085 f2fs_do_zero_range fs/f2fs/file.c:1657 [inline] f2fs_zero_range+0x10c1/0x1580 fs/f2fs/file.c:1737 f2fs_fallocate+0x583/0x990 fs/f2fs/file.c:2030 vfs_fallocate+0x669/0x7e0 fs/open.c:342 ioctl_preallocate fs/ioctl.c:289 [inline] file_ioctl+0x611/0x780 fs/ioctl.c:-1 do_vfs_ioctl+0xb33/0x1430 fs/ioctl.c:576 __do_sys_ioctl fs/ioctl.c:595 [inline] __se_sys_ioctl+0x82/0x170 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f07bc58eec9In error path of f2fs_zero_range(), it may add a zero-sized extentinto extent cache, it should be avoided.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68797 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:char: applicom: fix NULL pointer dereference in ac_ioctlDiscovered by Atuin - Automated Vulnerability Discovery Engine.In ac_ioctl, the validation of IndexCard and the check for a validRamIO pointer are skipped when cmd is 6. However, the functionunconditionally executes readb(apbs[IndexCard].RamIO + VERS) at theend.If cmd is 6, IndexCard may reference a board that does not exist(where RamIO is NULL), leading to a NULL pointer dereference.Fix this by skipping the readb access when cmd is 6, as thiscommand is a global information query and does not target a specificboard context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: vidtv: initialize local pointers upon transfer of memory ownershipvidtv_channel_si_init() creates a temporary list (program, service, event)and ownership of the memory itself is transferred to the PAT/SDT/EITtables through vidtv_psi_pat_program_assign(),vidtv_psi_sdt_service_assign(), vidtv_psi_eit_event_assign().The problem here is that the local pointer where the memory ownershiptransfer was completed is not initialized to NULL. This causes thevidtv_psi_pmt_create_sec_for_each_pat_entry() function to fail, andin the flow that jumps to free_eit, the memory that was freed byvidtv_psi_*_table_destroy() can be accessed again byvidtv_psi_*_event_destroy() due to the uninitialized local pointer, so itis freed once again.Therefore, to prevent use-after-free and double-free vulnerability,local pointers must be initialized to NULL when transferring memoryownership.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68815 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Remove drr class from the active list if it changes to strictWhenever a user issues an ets qdisc change command, transforming adrr class into a strict one, the ets code isn't checking whether thatclass was in the active list and removing it. This means that, if auser changes a strict class (which was in the active list) back to a drrone, that class will be added twice to the active list [1].Doing so with the following commands:tc qdisc add dev lo root handle 1: ets bands 2 strict 1tc qdisc add dev lo parent 1:2 handle 20: \ tbf rate 8bit burst 100b latency 1stc filter add dev lo parent 1: basic classid 1:2ping -c1 -W0.01 -s 56 127.0.0.1tc qdisc change dev lo root handle 1: ets bands 2 strict 2tc qdisc change dev lo root handle 1: ets bands 2 strict 1ping -c1 -W0.01 -s 56 127.0.0.1Will trigger the following splat with list debug turned on:[ 59.279014][ T365] ------------[ cut here ]------------[ 59.279452][ T365] list_add double add: new=ffff88801d60e350, prev=ffff88801d60e350, next=ffff88801d60e2c0.[ 59.280153][ T365] WARNING: CPU: 3 PID: 365 at lib/list_debug.c:35 __list_add_valid_or_report+0x17f/0x220[ 59.280860][ T365] Modules linked in:[ 59.281165][ T365] CPU: 3 UID: 0 PID: 365 Comm: tc Not tainted 6.18.0-rc7-00105-g7e9f13163c13-dirty #239 PREEMPT(voluntary)[ 59.281977][ T365] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011[ 59.282391][ T365] RIP: 0010:__list_add_valid_or_report+0x17f/0x220[ 59.282842][ T365] Code: 89 c6 e8 d4 b7 0d ff 90 0f 0b 90 90 31 c0 e9 31 ff ff ff 90 48 c7 c7 e0 a0 22 9f 48 89 f2 48 89 c1 4c 89 c6 e8 b2 b7 0d ff 90 <0f> 0b 90 90 31 c0 e9 0f ff ff ff 48 89 f7 48 89 44 24 10 4c 89 44...[ 59.288812][ T365] Call Trace:[ 59.289056][ T365] [ 59.289224][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.289546][ T365] ets_qdisc_change+0xd2b/0x1e80[ 59.289891][ T365] ? __lock_acquire+0x7e7/0x1be0[ 59.290223][ T365] ? __pfx_ets_qdisc_change+0x10/0x10[ 59.290546][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.290898][ T365] ? __mutex_trylock_common+0xda/0x240[ 59.291228][ T365] ? __pfx___mutex_trylock_common+0x10/0x10[ 59.291655][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.291993][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.292313][ T365] ? trace_contention_end+0xc8/0x110[ 59.292656][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293022][ T365] ? srso_alias_return_thunk+0x5/0xfbef5[ 59.293351][ T365] tc_modify_qdisc+0x63a/0x1cf0Fix this by always checking and removing an ets class from the active listwhen changing it to strict.[1] https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/tree/net/sched/sch_ets.c?id=ce052b9402e461a9aded599f5b47e76bc727f7de#n663

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68816 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fw_tracer, Validate format string parametersAdd validation for format string parameters in the firmware tracer toprevent potential security vulnerabilities and crashes from malformedformat strings received from firmware.The firmware tracer receives format strings from the device firmware anduses them to format trace messages. Without proper validation, badfirmware could provide format strings with invalid format specifiers(e.g., %s, %p, %n) that could lead to crashes, or other undefinedbehavior.Add mlx5_tracer_validate_params() to validate that all format specifiersin trace strings are limited to safe integer/hex formats (%x, %d, %i,%u, %llx, %lx, etc.). Reject strings containing other format types thatcould be used to access arbitrary memory or cause crashes.Invalid format strings are added to the trace output for visibility with"BAD_FORMAT: " prefix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68818 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: Revert "scsi: qla2xxx: Perform lockless command completion in abort path"This reverts commit 0367076b0817d5c75dfb83001ce7ce5c64d803a9.The commit being reverted added code to __qla2x00_abort_all_cmds() tocall sp->done() without holding a spinlock. But unlike the older codebelow it, this new code failed to check sp->cmd_type and just assumedTYPE_SRB, which results in a jump to an invalid pointer in target-modewith TYPE_TGT_CMD:qla2xxx [0000:65:00.0]-d034:8: qla24xx_do_nack_work create sess success 0000000009f7a79bqla2xxx [0000:65:00.0]-5003:8: ISP System Error - mbx1=1ff5h mbx2=10h mbx3=0h mbx4=0h mbx5=191h mbx6=0h mbx7=0h.qla2xxx [0000:65:00.0]-d01e:8: -> fwdump no bufferqla2xxx [0000:65:00.0]-f03a:8: qla_target(0): System error async event 0x8002 occurredqla2xxx [0000:65:00.0]-00af:8: Performing ISP error recovery - ha=0000000058183fda.BUG: kernel NULL pointer dereference, address: 0000000000000000PF: supervisor instruction fetch in kernel modePF: error_code(0x0010) - not-present pagePGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9446 Comm: qla2xxx_8_dpc Tainted: G O 6.1.133 #1Hardware name: Supermicro Super Server/X11SPL-F, BIOS 4.2 12/15/2023RIP: 0010:0x0Code: Unable to access opcode bytes at 0xffffffffffffffd6.RSP: 0018:ffffc90001f93dc8 EFLAGS: 00010206RAX: 0000000000000282 RBX: 0000000000000355 RCX: ffff88810d16a000RDX: ffff88810dbadaa8 RSI: 0000000000080000 RDI: ffff888169dc38c0RBP: ffff888169dc38c0 R08: 0000000000000001 R09: 0000000000000045R10: ffffffffa034bdf0 R11: 0000000000000000 R12: ffff88810800bb40R13: 0000000000001aa8 R14: ffff888100136610 R15: ffff8881070f7400FS: 0000000000000000(0000) GS:ffff88bf80080000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffffffffffffd6 CR3: 000000010c8ff006 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __die+0x4d/0x8b ? page_fault_oops+0x91/0x180 ? trace_buffer_unlock_commit_regs+0x38/0x1a0 ? exc_page_fault+0x391/0x5e0 ? asm_exc_page_fault+0x22/0x30 __qla2x00_abort_all_cmds+0xcb/0x3e0 [qla2xxx_scst] qla2x00_abort_all_cmds+0x50/0x70 [qla2xxx_scst] qla2x00_abort_isp_cleanup+0x3b7/0x4b0 [qla2xxx_scst] qla2x00_abort_isp+0xfd/0x860 [qla2xxx_scst] qla2x00_do_dpc+0x581/0xa40 [qla2xxx_scst] kthread+0xa8/0xd0 Then commit 4475afa2646d ("scsi: qla2xxx: Complete command early withinlock") added the spinlock back, because not having the lock caused arace and a crash. But qla2x00_abort_srb() in the switch below alreadychecks for qla2x00_chip_is_down() and handles it the same way, so thecode above the switch is now redundant and still buggy in target-mode.Remove it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: dtv5100: fix out-of-bounds in dtv5100_i2c_msg()rlen value is a user-controlled value, but dtv5100_i2c_msg() does notcheck the size of the rlen value. Therefore, if it is set to a valuelarger than sizeof(st->data), an out-of-bounds vuln occurs for st->data.Therefore, we need to add proper range checking to prevent this vuln.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68822 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: alps - fix use-after-free bugs caused by dev3_register_workThe dev3_register_work delayed work item is initialized withinalps_reconnect() and scheduled upon receipt of the first barePS/2 packet from an external PS/2 device connected to the ALPStouchpad. During device detachment, the original implementationcalls flush_workqueue() in psmouse_disconnect() to ensurecompletion of dev3_register_work. However, the flush_workqueue()in psmouse_disconnect() only blocks and waits for work items thatwere already queued to the workqueue prior to its invocation. Anywork items submitted after flush_workqueue() is called are notincluded in the set of tasks that the flush operation awaits.This means that after flush_workqueue() has finished executing,the dev3_register_work could still be scheduled. Although thepsmouse state is set to PSMOUSE_CMD_MODE in psmouse_disconnect(),the scheduling of dev3_register_work remains unaffected.The race condition can occur as follows:CPU 0 (cleanup path) | CPU 1 (delayed work)psmouse_disconnect() | psmouse_set_state() | flush_workqueue() | alps_report_bare_ps2_packet() alps_disconnect() | psmouse_queue_work() kfree(priv); // FREE | alps_register_bare_ps2_mouse() | priv = container_of(work...); // USE | priv->dev3 // USEAdd disable_delayed_work_sync() in alps_disconnect() to ensurethat dev3_register_work is properly canceled and prevented fromexecuting after the alps_data structure has been deallocated.This bug is identified by static analysis.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: using the num_tqps in the vf driver to apply for resourcesCurrently, hdev->htqp is allocated using hdev->num_tqps, and kinfo->tqpis allocated using kinfo->num_tqps. However, kinfo->num_tqps is set tomin(new_tqps, hdev->num_tqps); Therefore, kinfo->num_tqps may be smallerthan hdev->num_tqps, which causes some hdev->htqp[i] to remainuninitialized in hclgevf_knic_setup().Thus, this patch allocates hdev->htqp and kinfo->tqp using hdev->num_tqps,ensuring that the lengths of hdev->htqp and kinfo->tqp are consistentand that all elements are properly initialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71066 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: ets: Always remove class from active list before deleting in ets_qdisc_changezdi-disclosures@trendmicro.com says:The vulnerability is a race condition between `ets_qdisc_dequeue` and`ets_qdisc_change`. It leads to UAF on `struct Qdisc` object.Attacker requires the capability to create new user and network namespacein order to trigger the bug.See my additional commentary at the end of the analysis.Analysis:static int ets_qdisc_change(struct Qdisc *sch, struct nlattr *opt, struct netlink_ext_ack *extack){... // (1) this lock is preventing .change handler (`ets_qdisc_change`) //to race with .dequeue handler (`ets_qdisc_dequeue`) sch_tree_lock(sch); for (i = nbands; i < oldbands; i++) { if (i >= q->nstrict && q->classes[i].qdisc->q.qlen) list_del_init(&q->classes[i].alist); qdisc_purge_queue(q->classes[i].qdisc); } WRITE_ONCE(q->nbands, nbands); for (i = nstrict; i < q->nstrict; i++) { if (q->classes[i].qdisc->q.qlen) { // (2) the class is added to the q->active list_add_tail(&q->classes[i].alist, &q->active); q->classes[i].deficit = quanta[i]; } } WRITE_ONCE(q->nstrict, nstrict); memcpy(q->prio2band, priomap, sizeof(priomap)); for (i = 0; i < q->nbands; i++) WRITE_ONCE(q->classes[i].quantum, quanta[i]); for (i = oldbands; i < q->nbands; i++) { q->classes[i].qdisc = queues[i]; if (q->classes[i].qdisc != &noop_qdisc) qdisc_hash_add(q->classes[i].qdisc, true); } // (3) the qdisc is unlocked, now dequeue can be called in parallel // to the rest of .change handler sch_tree_unlock(sch); ets_offload_change(sch); for (i = q->nbands; i < oldbands; i++) { // (4) we're reducing the refcount for our class's qdisc and // freeing it qdisc_put(q->classes[i].qdisc); // (5) If we call .dequeue between (4) and (5), we will have // a strong UAF and we can control RIP q->classes[i].qdisc = NULL; WRITE_ONCE(q->classes[i].quantum, 0); q->classes[i].deficit = 0; gnet_stats_basic_sync_init(&q->classes[i].bstats); memset(&q->classes[i].qstats, 0, sizeof(q->classes[i].qstats)); } return 0;}Comment:This happens because some of the classes have their qdiscs assigned toNULL, but remain in the active list. This commit fixes this issue by alwaysremoving the class from the active list before deleting and freeing itsassociated qdiscReproducer Steps(trimmed version of what was sent by zdi-disclosures@trendmicro.com)```DEV="${DEV:-lo}"ROOT_HANDLE="${ROOT_HANDLE:-1:}"BAND2_HANDLE="${BAND2_HANDLE:-20:}" # child under 1:2PING_BYTES="${PING_BYTES:-48}"PING_COUNT="${PING_COUNT:-200000}"PING_DST="${PING_DST:-127.0.0.1}"SLOW_TBF_RATE="${SLOW_TBF_RATE:-8bit}"SLOW_TBF_BURST="${SLOW_TBF_BURST:-100b}"SLOW_TBF_LAT="${SLOW_TBF_LAT:-1s}"cleanup() { tc qdisc del dev "$DEV" root 2>/dev/null}trap cleanup EXITip link set "$DEV" uptc qdisc del dev "$DEV" root 2>/dev/null || truetc qdisc add dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc qdisc add dev "$DEV" parent 1:2 handle "$BAND2_HANDLE" \ tbf rate "$SLOW_TBF_RATE" burst "$SLOW_TBF_BURST" latency "$SLOW_TBF_LAT"tc filter add dev "$DEV" parent 1: protocol all prio 1 u32 match u32 0 0 flowid 1:2tc -s qdisc ls dev $DEVping -I "$DEV" -f -c "$PING_COUNT" -s "$PING_BYTES" -W 0.001 "$PING_DST" \ >/dev/null 2>&1 &tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 0tc qdisc change dev "$DEV" root handle "$ROOT_HANDLE" ets bands 2 strict 2tc -s qdisc ls dev $DEVtc qdisc del dev "$DEV" parent ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71068 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:svcrdma: bound check rq_pages index in inline pathsvc_rdma_copy_inline_range indexed rqstp->rq_pages[rc_curpage] withoutverifying rc_curpage stays within the allocated page array. Add guardsbefore the first use and after advancing to a new page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: invalidate dentry cache on failed whiteout creationF2FS can mount filesystems with corrupted directory depth values thatget runtime-clamped to MAX_DIR_HASH_DEPTH. When RENAME_WHITEOUToperations are performed on such directories, f2fs_rename performsdirectory modifications (updating target entry and deleting sourceentry) before attempting to add the whiteout entry via f2fs_add_link.If f2fs_add_link fails due to the corrupted directory structure, thefunction returns an error to VFS, but the partial directorymodifications have already been committed to disk. VFS assumes theentire rename operation failed and does not update the dentry cache,leaving stale mappings.In the error path, VFS does not call d_move() to update the dentrycache. This results in new_dentry still pointing to the old inode(new_inode) which has already had its i_nlink decremented to zero.The stale cache causes subsequent operations to incorrectly referencethe freed inode.This causes subsequent operations to use cached dentry information thatno longer matches the on-disk state. When a second rename targets thesame entry, VFS attempts to decrement i_nlink on the stale inode, whichmay already have i_nlink=0, triggering a WARNING in drop_nlink().Example sequence:1. First rename (RENAME_WHITEOUT): file2 -> file1 - f2fs updates file1 entry on disk (points to inode 8) - f2fs deletes file2 entry on disk - f2fs_add_link(whiteout) fails (corrupted directory) - Returns error to VFS - VFS does not call d_move() due to error - VFS cache still has: file1 -> inode 7 (stale!) - inode 7 has i_nlink=0 (already decremented)2. Second rename: file3 -> file1 - VFS uses stale cache: file1 -> inode 7 - Tries to drop_nlink on inode 7 (i_nlink already 0) - WARNING in drop_nlink()Fix this by explicitly invalidating old_dentry and new_dentry whenf2fs_add_link fails during whiteout creation. This forces VFS torefresh from disk on subsequent operations, ensuring cache consistencyeven when the rename partially succeeds.Reproducer:1. Mount F2FS image with corrupted i_current_depth2. renameat2(file2, file1, RENAME_WHITEOUT)3. renameat2(file3, file1, 0)4. System triggers WARNING in drop_nlink()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71074 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:functionfs: fix the open/removal racesffs_epfile_open() can race with removal, ending up with file->private_datapointing to freed object.There is a total count of opened files on functionfs (both ep0 anddynamic ones) and when it hits zero, dynamic files get removed.Unfortunately, that removal can happen while another thread isin ffs_epfile_open(), but has not incremented the count yet.In that case open will succeed, leaving us with UAF on any subsequentread() or write().The root cause is that ffs->opened is misused; atomic_dec_and_test() vs.atomic_add_return() is not a good idea, when object remains visible allalong.To untangle that * serialize openers on ffs->mutex (both for ep0 and for dynamic files) * have dynamic ones use atomic_inc_not_zero() and fail if we hadzero ->opened; in that case the file we are opening is doomed. * have the inodes of dynamic files marked on removal (from thecallback of simple_recursive_removal()) - clear ->i_private there. * have open of dynamic ones verify they hadn't been already removed,along with checking that state is FFS_ACTIVE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71075 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: aic94xx: fix use-after-free in device removal pathThe asd_pci_remove() function fails to synchronize with pending taskletsbefore freeing the asd_ha structure, leading to a potentialuse-after-free vulnerability.When a device removal is triggered (via hot-unplug or module unload),race condition can occur.The fix adds tasklet_kill() before freeing the asd_ha structure,ensuring all scheduled tasklets complete before cleanup proceeds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71077 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: Cap the number of PCR bankstpm2_get_pcr_allocation() does not cap any upper limit for the number ofbanks. Cap the limit to eight banks so that out of bounds values comingfrom external I/O cause on only limited harm.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71078 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s/slb: Fix SLB multihit issue during SLB preloadOn systems using the hash MMU, there is a software SLB preload cache thatmirrors the entries loaded into the hardware SLB buffer. This preloadcache is subject to periodic eviction - typically after every 256 contextswitches - to remove old entry.To optimize performance, the kernel skips switch_mmu_context() inswitch_mm_irqs_off() when the prev and next mm_struct are the same.However, on hash MMU systems, this can lead to inconsistencies betweenthe hardware SLB and the software preload cache.If an SLB entry for a process is evicted from the software cache on oneCPU, and the same process later runs on another CPU without executingswitch_mmu_context(), the hardware SLB may retain stale entries. If thekernel then attempts to reload that entry, it can trigger an SLBmulti-hit error.The following timeline shows how stale SLB entries are created and cancause a multi-hit error when a process moves between CPUs without aMMU context switch.CPU 0 CPU 1----- -----Process Pexec swapper/1 load_elf_binary begin_new_exc activate_mm switch_mm_irqs_off switch_mmu_context switch_slb /* * This invalidates all * the entries in the HW * and setup the new HW * SLB entries as per the * preload cache. */context_switchsched_migrate_task migrates process P to cpu-1Process swapper/0 context switch (to process P)(uses mm_struct of Process P) switch_mm_irqs_off() switch_slb load_slb++ /* * load_slb becomes 0 here * and we evict an entry from * the preload cache with * preload_age(). We still * keep HW SLB and preload * cache in sync, that is * because all HW SLB entries * anyways gets evicted in * switch_slb during SLBIA. * We then only add those * entries back in HW SLB, * which are currently * present in preload_cache * (after eviction). */ load_elf_binary continues... setup_new_exec() slb_setup_new_exec() sched_switch event sched_migrate_task migrates process P to cpu-0context_switch from swapper/0 to Process P switch_mm_irqs_off() /* * Since both prev and next mm struct are same we don't call * switch_mmu_context(). This will cause the HW SLB and SW preload * cache to go out of sync in preload_new_slb_context. Because there * was an SLB entry which was evicted from both HW and preload cache * on cpu-1. Now later in preload_new_slb_context(), when we will try * to add the same preload entry again, we will add this to the SW * preload cache and then will add it to the HW SLB. Since on cpu-0 * this entry was never invalidated, hence adding this entry to the HW * SLB will cause a SLB multi-hit error. */load_elf_binary cont---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71079 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_writeA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()due to lock ordering inversion between device_lock and rfkill_global_mutex.The problematic lock order is:Thread A (rfkill_fop_write): rfkill_fop_write() mutex_lock(&rfkill_global_mutex) rfkill_set_block() nfc_rfkill_set_block() nfc_dev_down() device_lock(&dev->dev) <- waits for device_lockThread B (nfc_unregister_device): nfc_unregister_device() device_lock(&dev->dev) rfkill_unregister() mutex_lock(&rfkill_global_mutex) <- waits for rfkill_global_mutexThis creates a classic ABBA deadlock scenario.Fix this by moving rfkill_unregister() and rfkill_destroy() outside thedevice_lock critical section. Store the rfkill pointer in a local variablebefore releasing the lock, then call rfkill_unregister() after releasingdevice_lock.This change is safe because rfkill_fop_write() holds rfkill_global_mutexwhile calling the rfkill callbacks, and rfkill_unregister() also acquiresrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() willwait for any ongoing callback to complete before proceeding, anddevice_del() is only called after rfkill_unregister() returns, preventingany use-after-free.The similar lock ordering in nfc_register_device() (device_lock ->rfkill_global_mutex via rfkill_register) is safe because duringregistration the device is not yet in rfkill_list, so no concurrentrfkill operations can occur on this device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71082 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: revert use of devm_kzalloc in btusbThis reverts commit 98921dbd00c4e ("Bluetooth: Use devm_kzalloc inbtusb.c file").In btusb_probe(), we use devm_kzalloc() to allocate the btusb data. Thisties the lifetime of all the btusb data to the binding of a driver toone interface, INTF. In a driver that binds to other interfaces, ISOCand DIAG, this is an accident waiting to happen.The issue is revealed in btusb_disconnect(), where callingusb_driver_release_interface(&btusb_driver, data->intf) will have devmfree the data that is also being used by the other interfaces of thedriver that may not be released yet.To fix this, revert the use of devm and go back to freeing memoryexplicitly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71083 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Avoid NULL pointer deref for evicted BOsIt is possible for a BO to exist that is not currently associated with aresource, e.g. because it has been evicted.When devcoredump tries to read the contents of all BOs for dumping, we needto expect this as well -- in this case, ENODATA is recorded instead of thebuffer contents.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix the crash issue for zero copy XDP_TX actionThere is a crash issue when running zero copy XDP_TX action, the crashlog is shown below.[ 216.122464] Unable to handle kernel paging request at virtual address fffeffff80000000[ 216.187524] Internal error: Oops: 0000000096000144 [#1] SMP[ 216.301694] Call trace:[ 216.304130] dcache_clean_poc+0x20/0x38 (P)[ 216.308308] __dma_sync_single_for_device+0x1bc/0x1e0[ 216.313351] stmmac_xdp_xmit_xdpf+0x354/0x400[ 216.317701] __stmmac_xdp_run_prog+0x164/0x368[ 216.322139] stmmac_napi_poll_rxtx+0xba8/0xf00[ 216.326576] __napi_poll+0x40/0x218[ 216.408054] Kernel panic - not syncing: Oops: Fatal exception in interruptFor XDP_TX action, the xdp_buff is converted to xdp_frame byxdp_convert_buff_to_frame(). The memory type of the resulting xdp_framedepends on the memory type of the xdp_buff. For page pool based xdp_buffit produces xdp_frame with memory type MEM_TYPE_PAGE_POOL. For zero copyXSK pool based xdp_buff it produces xdp_frame with memory typeMEM_TYPE_PAGE_ORDER0. However, stmmac_xdp_xmit_back() does not check thememory type and always uses the page pool type, this leads to invalidmappings and causes the crash. Therefore, check the xdp_buff memory typein stmmac_xdp_xmit_back() to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71098 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_gre: make ip6gre_header() robustOver the years, syzbot found many ways to crash the kernelin ip6gre_header() [1].This involves team or bonding drivers ability to dynamicallychange their dev->needed_headroom and/or dev->hard_header_lenIn this particular crash mld_newpack() allocated an skbwith a too small reserve/headroom, and by the time mld_sendpack()was called, syzbot managed to attach an ip6gre device.[1]skbuff: skb_under_panic: text:ffffffff8a1d69a8 len:136 put:40 head:ffff888059bc7000 data:ffff888059bc6fe8 tail:0x70 end:0x6c0 dev:team0------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:213 ! skb_under_panic net/core/skbuff.c:223 [inline] skb_push+0xc3/0xe0 net/core/skbuff.c:2641 ip6gre_header+0xc8/0x790 net/ipv6/ip6_gre.c:1371 dev_hard_header include/linux/netdevice.h:3436 [inline] neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618 neigh_output include/net/neighbour.h:556 [inline] ip6_finish_output2+0xfb3/0x1480 net/ipv6/ip6_output.c:136 __ip6_finish_output net/ipv6/ip6_output.c:-1 [inline] ip6_finish_output+0x234/0x7d0 net/ipv6/ip6_output.c:220 NF_HOOK_COND include/linux/netfilter.h:307 [inline] ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247 NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318 mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855 mld_send_cr net/ipv6/mcast.c:2154 [inline] mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71105 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: use global inline_xattr_slab instead of per-sb slab cacheAs Hong Yun reported in mailing list:loop7: detected capacity change from 0 to 131072------------[ cut here ]------------kmem_cache of name 'f2fs_xattr_entry-7:7' already existsWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe bug can be reproduced w/ below scripts:- mount /dev/vdb /mnt1- mount /dev/vdc /mnt2- umount /mnt1- mounnt /dev/vdb /mnt1The reason is if we created two slab caches, named f2fs_xattr_entry-7:3and f2fs_xattr_entry-7:7, and they have the same slab size. Actually,slab system will only create one slab cache core structure which hasslab name of "f2fs_xattr_entry-7:3", and two slab caches share the samestructure and cache address.So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it willdecrease reference count of slab cache, rather than release slab cacheentirely, since there is one more user has referenced the cache.Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again,slab system will find that there is existed cache which has the same nameand trigger the warning.Let's changes to use global inline_xattr_slab instead of per-sb slab cachefor fixing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71108 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Handle incorrect num_connectors capabilityThe UCSI spec states that the num_connectors field is 7 bits, and the8th bit is reserved and should be set to zero.Some buggy FW has been known to set this bit, and it can lead to asystem not booting.Flag that the FW is not behaving correctly, and auto-fix the valueso that the system boots correctly.Found on Lenovo P1 G8 during Linux enablement program. The FW willbe fixed, but seemed worth addressing in case it hit platforms thataren't officially Linux supported.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71111 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (w83791d) Convert macros to functions to avoid TOCTOUThe macro FAN_FROM_REG evaluates its arguments multiple times. When usedin lockless contexts involving shared driver data, this leads toTime-of-Check to Time-of-Use (TOCTOU) race conditions, potentiallycausing divide-by-zero errors.Convert the macro to a static function. This guarantees that argumentsare evaluated only once (pass-by-value), preventing the raceconditions.Additionally, in store_fan_div, move the calculation of the minimumlimit inside the update lock. This ensures that the read-modify-writesequence operates on consistent data.Adhere to the principle of minimal changes by only converting macrosthat evaluate arguments multiple times and are used in locklesscontexts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71118 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: Avoid walking the Namespace if start_node is NULLAlthough commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespaceif it is not there") fixed the situation when both start_node andacpi_gbl_root_node are NULL, the Linux kernel mainline now still crashedon Honor Magicbook 14 Pro [1].That happens due to the access to the member of parent_node inacpi_ns_get_next_node(). The NULL pointer dereference will alwayshappen, no matter whether or not the start_node is equal toACPI_ROOT_OBJECT, so move the check of start_node being NULLout of the if block.Unfortunately, all the attempts to contact Honor have failed, theyrefused to provide any technical support for Linux.The bad DSDT table's dump could be found on GitHub [2].DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025[ rjw: Subject adjustment, changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71131 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: seqiv - Do not use req->iv after crypto_aead_encryptAs soon as crypto_aead_encrypt is called, the underlying requestmay be freed by an asynchronous completion. Thus dereferencingreq->iv after it returns is invalid.Instead of checking req->iv against info, create a new variableunaligned_info and use it for that purpose instead.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71133 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: avoid invalid read in irdma_net_eventirdma_net_event() should not dereference anything from "neigh" (alias"ptr") until it has checked that the event is NETEVENT_NEIGH_UPDATE.Other events come with different structures pointed to by "ptr" and theymay be smaller than struct neighbour.Move the read of neigh->dev under the NETEVENT_NEIGH_UPDATE case.The bug is mostly harmless, but it triggers KASAN on debug kernels: BUG: KASAN: stack-out-of-bounds in irdma_net_event+0x32e/0x3b0 [irdma] Read of size 8 at addr ffffc900075e07f0 by task kworker/27:2/542554 CPU: 27 PID: 542554 Comm: kworker/27:2 Kdump: loaded Not tainted 5.14.0-630.el9.x86_64+debug #1 Hardware name: [...] Workqueue: events rt6_probe_deferred Call Trace: dump_stack_lvl+0x60/0xb0 print_address_description.constprop.0+0x2c/0x3f0 print_report+0xb4/0x270 kasan_report+0x92/0xc0 irdma_net_event+0x32e/0x3b0 [irdma] notifier_call_chain+0x9e/0x180 atomic_notifier_call_chain+0x5c/0x110 rt6_do_redirect+0xb91/0x1080 tcp_v6_err+0xe9b/0x13e0 icmpv6_notify+0x2b2/0x630 ndisc_redirect_rcv+0x328/0x530 icmpv6_rcv+0xc16/0x1360 ip6_protocol_deliver_rcu+0xb84/0x12e0 ip6_input_finish+0x117/0x240 ip6_input+0xc4/0x370 ipv6_rcv+0x420/0x7d0 __netif_receive_skb_one_core+0x118/0x1b0 process_backlog+0xd1/0x5d0 __napi_poll.constprop.0+0xa3/0x440 net_rx_action+0x78a/0xba0 handle_softirqs+0x2d4/0x9c0 do_softirq+0xad/0xe0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71136 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: adv7842: Avoid possible out-of-bounds array accesses in adv7842_cp_log_status()It's possible for cp_read() and hdmi_read() to return -EIO. Thosevalues are further used as indexes for accessing arrays.Fix that by checking return values where it's needed.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71137 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: fix "UBSAN: shift-out-of-bounds error"This patch ensures that the RX ring size (rx_pending) is notset below the permitted length. This avoids UBSANshift-out-of-bounds errors when users passes small or zeroring sizes via ethtool -G.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2026-0990 Severity: Moderate CVSS3 score: 5.5

Description: A flaw was found in libxml2, an XML parsing library. This uncontrolled recursion vulnerability occurs in the xmlCatalogXMLResolveURI function when an XML catalog contains a delegate URI entry that references itself. A remote attacker could exploit this configuration-dependent issue by providing a specially crafted XML catalog, leading to infinite recursion and call stack exhaustion. This ultimately results in a segmentation fault, causing a Denial of Service (DoS) by crashing affected applications.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2026-22976 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: sch_qfq: Fix NULL deref when deactivating inactive aggregate in qfq_reset`qfq_class->leaf_qdisc->q.qlen > 0` does not imply that the classitself is active.Two qfq_class objects may point to the same leaf_qdisc. This happenswhen:1. one QFQ qdisc is attached to the dev as the root qdisc, and2. another QFQ qdisc is temporarily referenced (e.g., via qdisc_get()/ qdisc_put()) and is pending to be destroyed, as in functiontc_new_tfilter.When packets are enqueued through the root QFQ qdisc, the sharedleaf_qdisc->q.qlen increases. At the same time, the second QFQqdisc triggers qdisc_put and qdisc_destroy: the qdisc entersqfq_reset() with its own q->q.qlen == 0, but its class's leafqdisc->q.qlen > 0. Therefore, the qfq_reset would wrongly deactivatean inactive aggregate and trigger a null-deref in qfq_deactivate_agg:[ 0.903172] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 0.903571] #PF: supervisor write access in kernel mode[ 0.903860] #PF: error_code(0x0002) - not-present page[ 0.904177] PGD 10299b067 P4D 10299b067 PUD 10299c067 PMD 0[ 0.904502] Oops: Oops: 0002 [#1] SMP NOPTI[ 0.904737] CPU: 0 UID: 0 PID: 135 Comm: exploit Not tainted 6.19.0-rc3+ #2 NONE[ 0.905157] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014[ 0.905754] RIP: 0010:qfq_deactivate_agg (include/linux/list.h:992 (discriminator 2) include/linux/list.h:1006 (discriminator 2) net/sched/sch_qfq.c:1367 (discriminator 2) net/sched/sch_qfq.c:1393 (discriminator 2))[ 0.906046] Code: 0f 84 4d 01 00 00 48 89 70 18 8b 4b 10 48 c7 c2 ff ff ff ff 48 8b 78 08 48 d3 e2 48 21 f2 48 2b 13 48 8b 30 48 d3 ea 8b 4b 18 0Code starting with the faulting instruction=========================================== 0: 0f 84 4d 01 00 00 je 0x153 6: 48 89 70 18 mov %rsi,0x18(%rax) a: 8b 4b 10 mov 0x10(%rbx),%ecx d: 48 c7 c2 ff ff ff ff mov $0xffffffffffffffff,%rdx 14: 48 8b 78 08 mov 0x8(%rax),%rdi 18: 48 d3 e2 shl %cl,%rdx 1b: 48 21 f2 and %rsi,%rdx 1e: 48 2b 13 sub (%rbx),%rdx 21: 48 8b 30 mov (%rax),%rsi 24: 48 d3 ea shr %cl,%rdx 27: 8b 4b 18 mov 0x18(%rbx),%ecx ...[ 0.907095] RSP: 0018:ffffc900004a39a0 EFLAGS: 00010246[ 0.907368] RAX: ffff8881043a0880 RBX: ffff888102953340 RCX: 0000000000000000[ 0.907723] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000[ 0.908100] RBP: ffff888102952180 R08: 0000000000000000 R09: 0000000000000000[ 0.908451] R10: ffff8881043a0000 R11: 0000000000000000 R12: ffff888102952000[ 0.908804] R13: ffff888102952180 R14: ffff8881043a0ad8 R15: ffff8881043a0880[ 0.909179] FS: 000000002a1a0380(0000) GS:ffff888196d8d000(0000) knlGS:0000000000000000[ 0.909572] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 0.909857] CR2: 0000000000000000 CR3: 0000000102993002 CR4: 0000000000772ef0[ 0.910247] PKRU: 55555554[ 0.910391] Call Trace:[ 0.910527] [ 0.910638] qfq_reset_qdisc (net/sched/sch_qfq.c:357 net/sched/sch_qfq.c:1485)[ 0.910826] qdisc_reset (include/linux/skbuff.h:2195 include/linux/skbuff.h:2501 include/linux/skbuff.h:3424 include/linux/skbuff.h:3430 net/sched/sch_generic.c:1036)[ 0.911040] __qdisc_destroy (net/sched/sch_generic.c:1076)[ 0.911236] tc_new_tfilter (net/sched/cls_api.c:2447)[ 0.911447] rtnetlink_rcv_msg (net/core/rtnetlink.c:6958)[ 0.911663] ? __pfx_rtnetlink_rcv_msg (net/core/rtnetlink.c:6861)[ 0.911894] netlink_rcv_skb (net/netlink/af_netlink.c:2550)[ 0.912100] netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)[ 0.912296] ? __alloc_skb (net/core/skbuff.c:706)[ 0.912484] netlink_sendmsg (net/netlink/af---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2019-19959 Severity: Moderate CVSS3 score: 5.4

Description: ext/misc/zipfile.c in SQLite 3.30.1 mishandles certain uses of INSERT INTO in situations involving embedded '\0' characters in filenames, leading to a memory-management error that can be detected by (for example) valgrind.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2020-13630 Severity: Moderate CVSS3 score: 5.4

Description: ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow, related to the snippet feature.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2020-26555 Severity: Moderate CVSS3 score: 5.4

Description: Bluetooth legacy BR/EDR PIN code pairing in Bluetooth Core Specification 1.0B through 5.2 may permit an unauthenticated nearby device to spoof the BD_ADDR of the peer device to complete pairing without knowledge of the PIN.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-22195 Severity: Moderate CVSS3 score: 5.4

Description: Jinja is an extensible templating engine. Special placeholders in the template allow writing code similar to Python syntax. It is possible to inject arbitrary HTML attributes into the rendered HTML template, potentially leading to Cross-Site Scripting (XSS). The Jinja `xmlattr` filter can be abused to inject arbitrary HTML attribute keys and values, bypassing the auto escaping mechanism and potentially leading to XSS. It may also be possible to bypass attribute validation checks if they are blacklist-based.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
python3-Jinja2 > 0-0 (version in image is 2.10.1-150000.3.21.1).

CVE-2025-48964 Severity: Moderate CVSS3 score: 5.4

Description: ping in iputils before 20250602 allows a denial of service (application error in adaptive ping mode or incorrect data collection) via a crafted ICMP Echo Reply packet, because a zero timestamp can lead to large intermediate values that have an integer overflow when squared during statistics calculations. NOTE: this issue exists because of an incomplete fix for CVE-2025-47268 (that fix was only about timestamp calculations, and it did not account for a specific scenario where the original timestamp in the ICMP payload is zero).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
iputils > 0-0 (version in image is 20211215-150400.3.22.1).

CVE-2025-7709 Severity: Moderate CVSS3 score: 5.4

Description: An integer overflow exists in the FTS5 https://sqlite.org/fts5.html extension. It occurs when the size of an array of tombstone pointers is calculated and truncated into a 32-bit integer. A pointer to partially controlled data can then be written out of bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsqlite3-0 > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2019-19924 Severity: Moderate CVSS3 score: 5.3

Description: SQLite 3.30.1 mishandles certain parser-tree rewriting, related to expr.c, vdbeaux.c, and window.c. This is caused by incorrect sqlite3WindowRewrite() error handling.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2022-48910 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: ensure we call ipv6_mc_down() at most onceThere are two reasons for addrconf_notify() to be called with NETDEV_DOWN:either the network device is actually going down, or IPv6 was disabledon the interface.If either of them stays down while the other is toggled, we repeatedlycall the code for NETDEV_DOWN, including ipv6_mc_down(), while nevercalling the corresponding ipv6_mc_up() in between. This will cause anew entry in idev->mc_tomb to be allocated for each multicast groupthe interface is subscribed to, which in turn leaks one struct ifmcaddr6per nontrivial multicast group the interface is subscribed to.The following reproducer will leak at least $n objects:ip addr add ff2e::4242/32 dev eth0 autojoinsysctl -w net.ipv6.conf.eth0.disable_ipv6=1for i in $(seq 1 $n); do ip link set up eth0; ip link set down eth0doneJoining groups with IPV6_ADD_MEMBERSHIP (unprivileged) or setting thesysctl net.ipv6.conf.eth0.forwarding to 1 (=> subscribing to ff02::2)can also be used to create a nontrivial idev->mc_list, which will theleak objects with the right up-down-sequence.Based on both sources for NETDEV_DOWN events the interface IPv6 stateshould be considered: - not ready if the network interface is not ready OR IPv6 is disabled for it - ready if the network interface is ready AND IPv6 is enabled for itThe functions ipv6_mc_up() and ipv6_down() should only be run when thisstate changes.Implement this by remembering when the IPv6 state is ready, and onlyrun ipv6_mc_down() if it actually changed from ready to not ready.The other direction (not ready -> ready) already works correctly, as: - the interface notification triggered codepath for NETDEV_UP / NETDEV_CHANGE returns early if ipv6 is disabled, and - the disable_ipv6=0 triggered codepath skips fully initializing the interface as long as addrconf_link_ready(dev) returns false - calling ipv6_mc_up() repeatedly does not leak anything

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49267 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: core: use sysfs_emit() instead of sprintf()sprintf() (still used in the MMC core for the sysfs output) is vulnerableto the buffer overflow. Use the new-fangled sysfs_emit() instead.Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50470 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:xhci: Remove device endpoints from bandwidth list when freeing the deviceEndpoints are normally deleted from the bandwidth list when they aredropped, before the virt device is freed.If xHC host is dying or being removed then the endpoints aren't droppedcleanly due to functions returning early to avoid interacting with anon-accessible host controller.So check and delete endpoints that are still on the bandwidth list whenfreeing the virt device.Solves a list_del corruption kernel crash when unbinding xhci-pci,caused by xhci_mem_cleanup() when it later tried to delete already freedendpoints from the bandwidth list.This only affects hosts that use software bandwidth checking, whichcurrenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50554 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: avoid double ->queue_rq() because of early timeoutDavid Jeffery found one double ->queue_rq() issue, so far it canbe triggered in VM use case because of long vmexit latency or preemptlatency of vCPU pthread or long page fault in vCPU pthread, then blockIO req could be timed out before queuing the request to hardware but aftercalling blk_mq_start_request() during ->queue_rq(), then timeout handlermay handle it by requeue, then double ->queue_rq() is caused, and kernelpanic.So far, it is driver's responsibility to cover the race between timeoutand completion, so it seems supposed to be solved in driver in theory,given driver has enough knowledge.But it is really one common problem, lots of driver could have similarissue, and could be hard to fix all affected drivers, even it isn't easyfor driver to handle the race. So David suggests this patch by drainingin-progress ->queue_rq() for solving this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50576 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: pch: Fix PCI device refcount leak in pch_request_dma()As comment of pci_get_slot() says, it returns a pci_device with itsrefcount increased. The caller must decrement the reference count bycalling pci_dev_put().Since 'dma_dev' is only used to filter the channel in filter(), we cancall pci_dev_put() before exiting from pch_request_dma(). Add themissing pci_dev_put() for the normal and error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50783 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: use proper req destructor for IPv6Before, only the destructor from TCP request sock in IPv4 was calledeven if the subflow was IPv6.It is important to use the right destructor to avoid memory leaks withsome advanced IPv6 features, e.g. when the request socks containspecific IPv6 options.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50817 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: hsr: avoid possible NULL deref in skb_clone()syzbot got a crash [1] in skb_clone(), caused by a bugin hsr_get_untagged_frame().When/if create_stripped_skb_hsr() returns NULL, we mustnot attempt to call skb_clone().While we are at it, replace a WARN_ONCE() by netdev_warn_once().[1]general protection fault, probably for non-canonical address 0xdffffc000000000f: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000078-0x000000000000007f]CPU: 1 PID: 754 Comm: syz-executor.0 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022RIP: 0010:skb_clone+0x108/0x3c0 net/core/skbuff.c:1641Code: 93 02 00 00 49 83 7c 24 28 00 0f 85 e9 00 00 00 e8 5d 4a 29 fa 4c 8d 75 7e 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 ea 03 <0f> b6 04 02 4c 89 f2 83 e2 07 38 d0 7f 08 84 c0 0f 85 9e 01 00 00RSP: 0018:ffffc90003ccf4e0 EFLAGS: 00010207RAX: dffffc0000000000 RBX: ffffc90003ccf5f8 RCX: ffffc9000c24b000RDX: 000000000000000f RSI: ffffffff8751cb13 RDI: 0000000000000000RBP: 0000000000000000 R08: 00000000000000f0 R09: 0000000000000140R10: fffffbfff181d972 R11: 0000000000000000 R12: ffff888161fc3640R13: 0000000000000a20 R14: 000000000000007e R15: ffffffff8dc5f620FS: 00007feb621e4700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007feb621e3ff8 CR3: 00000001643a9000 CR4: 00000000003506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:hsr_get_untagged_frame+0x4e/0x610 net/hsr/hsr_forward.c:164hsr_forward_do net/hsr/hsr_forward.c:461 [inline]hsr_forward_skb+0xcca/0x1d50 net/hsr/hsr_forward.c:623hsr_handle_frame+0x588/0x7c0 net/hsr/hsr_slave.c:69__netif_receive_skb_core+0x9fe/0x38f0 net/core/dev.c:5379__netif_receive_skb_one_core+0xae/0x180 net/core/dev.c:5483__netif_receive_skb+0x1f/0x1c0 net/core/dev.c:5599netif_receive_skb_internal net/core/dev.c:5685 [inline]netif_receive_skb+0x12f/0x8d0 net/core/dev.c:5744tun_rx_batched+0x4ab/0x7a0 drivers/net/tun.c:1544tun_get_user+0x2686/0x3a00 drivers/net/tun.c:1995tun_chr_write_iter+0xdb/0x200 drivers/net/tun.c:2025call_write_iter include/linux/fs.h:2187 [inline]new_sync_write fs/read_write.c:491 [inline]vfs_write+0x9e9/0xdd0 fs/read_write.c:584ksys_write+0x127/0x250 fs/read_write.c:637do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-47627 Severity: Moderate CVSS3 score: 5.3

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when AIOHTTP_NO_EXTENSIONS is enabled (or not using a prebuilt wheel). These bugs have been addressed in commit `d5c12ba89` which has been included in release version 3.8.6. Users are advised to upgrade. There are no known workarounds for these issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2023-53535 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: bcmgenet: Add a check for oversized packetsOccasionnaly we may get oversized packets from the hardware whichexceed the nomimal 2KiB buffer size we allocate SKBs with. Add an earlycheck which drops the packet to avoid invoking skb_over_panic() and moveon to processing the next packet.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53622 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix possible data races in gfs2_show_options()Some fields such as gt_logd_secs of the struct gfs2_tune are accessedwithout holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val);And thus can cause data races when gfs2_show_options() and other functionssuch as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit;To fix these possible data races, the lock sdp->sd_tune.gt_spin isacquired before accessing the fields of gfs2_tune and released after theseaccesses.Further changes by Andreas:- Don't hold the spin lock over the seq_printf operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53711 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix a potential data corruptionWe must ensure that the subrequests are joined back into the head beforewe can retransmit a request. If the head was not on the commit lists,because the server wrote it synchronously, we still need to add it backto the retransmission list.Add a call that mirrors the effect of nfs_cancel_remove_inode() forO_DIRECT.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53718 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Do not swap cpu_buffer during resize processWhen ring_buffer_swap_cpu was called during resize process,the cpu buffer was swapped in the middle, resulting in incorrect state.Continuing to run in the wrong state will result in oops.This issue can be easily reproduced using the following two scripts:/tmp # cat test1.sh//#! /bin/shfor i in `seq 0 100000`do echo 2000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5 echo 5000 > /sys/kernel/debug/tracing/buffer_size_kb sleep 0.5done/tmp # cat test2.sh//#! /bin/shfor i in `seq 0 100000`do echo irqsoff > /sys/kernel/debug/tracing/current_tracer sleep 1 echo nop > /sys/kernel/debug/tracing/current_tracer sleep 1done/tmp # ./test1.sh &/tmp # ./test2.sh &A typical oops log is as follows, sometimes with other different oops logs.[ 231.711293] WARNING: CPU: 0 PID: 9 at kernel/trace/ring_buffer.c:2026 rb_update_pages+0x378/0x3f8[ 231.713375] Modules linked in:[ 231.714735] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 231.716750] Hardware name: linux,dummy-virt (DT)[ 231.718152] Workqueue: events update_pages_handler[ 231.719714] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 231.721171] pc : rb_update_pages+0x378/0x3f8[ 231.722212] lr : rb_update_pages+0x25c/0x3f8[ 231.723248] sp : ffff800082b9bd50[ 231.724169] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 0000000000000000[ 231.726102] x26: 0000000000000001 x25: fffffffffffff010 x24: 0000000000000ff0[ 231.728122] x23: ffff0000c3a0b600 x22: ffff0000c3a0b5c0 x21: fffffffffffffe0a[ 231.730203] x20: ffff0000c3a0b600 x19: ffff0000c0102400 x18: 0000000000000000[ 231.732329] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffe7aa8510[ 231.734212] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000002[ 231.736291] x11: ffff8000826998a8 x10: ffff800082b9baf0 x9 : ffff800081137558[ 231.738195] x8 : fffffc00030e82c8 x7 : 0000000000000000 x6 : 0000000000000001[ 231.740192] x5 : ffff0000ffbafe00 x4 : 0000000000000000 x3 : 0000000000000000[ 231.742118] x2 : 00000000000006aa x1 : 0000000000000001 x0 : ffff0000c0007208[ 231.744196] Call trace:[ 231.744892] rb_update_pages+0x378/0x3f8[ 231.745893] update_pages_handler+0x1c/0x38[ 231.746893] process_one_work+0x1f0/0x468[ 231.747852] worker_thread+0x54/0x410[ 231.748737] kthread+0x124/0x138[ 231.749549] ret_from_fork+0x10/0x20[ 231.750434] ---[ end trace 0000000000000000 ]---[ 233.720486] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000[ 233.721696] Mem abort info:[ 233.721935] ESR = 0x0000000096000004[ 233.722283] EC = 0x25: DABT (current EL), IL = 32 bits[ 233.722596] SET = 0, FnV = 0[ 233.722805] EA = 0, S1PTW = 0[ 233.723026] FSC = 0x04: level 0 translation fault[ 233.723458] Data abort info:[ 233.723734] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[ 233.724176] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 233.724589] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 233.725075] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000104943000[ 233.725592] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000[ 233.726231] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[ 233.726720] Modules linked in:[ 233.727007] CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W 6.5.0-rc1-00276-g20edcec23f92 #15[ 233.727777] Hardware name: linux,dummy-virt (DT)[ 233.728225] Workqueue: events update_pages_handler[ 233.728655] pstate: 200000c5 (nzCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 233.729054] pc : rb_update_pages+0x1a8/0x3f8[ 233.729334] lr : rb_update_pages+0x154/0x3f8[ 233.729592] sp : ffff800082b9bd50[ 233.729792] x29: ffff800082b9bd50 x28: ffff8000825f7000 x27: 00000000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53728 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:posix-timers: Ensure timer ID search-loop limit is validposix_timer_add() tries to allocate a posix timer ID by starting from thecached ID which was stored by the last successful allocation.This is done in a loop searching the ID space for a free slot one byone. The loop has to terminate when the search wrapped around to thestarting point.But that's racy vs. establishing the starting point. That is read outlockless, which leads to the following problem:CPU0 CPU1posix_timer_add() start = sig->posix_timer_id; lock(hash_lock); ... posix_timer_add() if (++sig->posix_timer_id < 0) start = sig->posix_timer_id; sig->posix_timer_id = 0;So CPU1 can observe a negative start value, i.e. -1, and the loop breaknever happens because the condition can never be true: if (sig->posix_timer_id == start) break;While this is unlikely to ever turn into an endless loop as the ID space ishuge (INT_MAX), the racy read of the start value caught the attention ofKCSAN and Dmitry unearthed that incorrectness.Rewrite it so that all id operations are under the hash lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53782 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix out of bounds access in DCCP error handlerThere was a previous attempt to fix an out-of-bounds access in the DCCPerror handlers, but that fix assumed that the error handlers only wantto access the first 8 bytes of the DCCP header. Actually, they also lookat the DCCP sequence number, which is stored beyond 8 bytes, so anexplicit pskb_may_pull() is required.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54118 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: setup GPIO controller later in probeThe GPIO controller component of the sc16is7xx driver is setup tooearly, which can result in a race condition where another device triesto utilise the GPIO lines before the sc16is7xx device has finishedinitialising.This issue manifests itself as an Oops when the GPIO lines are configured: Unable to handle kernel read from unreadable memory at virtual address ... pc : sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] lr : sc16is7xx_gpio_direction_output+0x4c/0x108 [sc16is7xx] ... Call trace: sc16is7xx_gpio_direction_output+0x68/0x108 [sc16is7xx] gpiod_direction_output_raw_commit+0x64/0x318 gpiod_direction_output+0xb0/0x170 create_gpio_led+0xec/0x198 gpio_led_probe+0x16c/0x4f0 platform_drv_probe+0x5c/0xb0 really_probe+0xe8/0x448 driver_probe_device+0xe8/0x138 __device_attach_driver+0x94/0x118 bus_for_each_drv+0x8c/0xe0 __device_attach+0x100/0x1b8 device_initial_probe+0x28/0x38 bus_probe_device+0xa4/0xb0 deferred_probe_work_func+0x90/0xe0 process_one_work+0x1c4/0x480 worker_thread+0x54/0x430 kthread+0x138/0x150 ret_from_fork+0x10/0x1cThis patch moves the setup of the GPIO controller functions to later in theprobe function, ensuring the sc16is7xx device has already finishedinitialising by the time other devices try to make use of the GPIO lines.The error handling has also been reordered to reflect the newinitialisation order.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-12243 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2024-22099 Severity: Moderate CVSS3 score: 5.3

Description: NULL Pointer Dereference vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (net, bluetooth modules) allows Overflow Buffers. This vulnerability is associated with program files /net/bluetooth/rfcomm/core.C.This issue affects Linux kernel: v2.6.12-rc2.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-23829 Severity: Moderate CVSS3 score: 5.3

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Security-sensitive parts of the Python HTTP parser retained minor differences in allowable character sets, that must trigger error handling to robustly match frame boundaries of proxies in order to protect against injection of additional requests. Additionally, validation could trigger exceptions that were not handled consistently with processing of other malformed input. Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling. The unhandled exception could cause excessive resource consumption on the application server and/or its logging facilities. This vulnerability exists due to an incomplete fix for CVE-2023-47627. Version 3.9.2 fixes this vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2024-23848 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel through 6.7.1, there is a use-after-free in cec_queue_msg_fh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27008 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm: nv04: Fix out of bounds accessWhen Output Resource (dcb->or) value is assigned infabricate_dcb_output(), there may be out of bounds access todac_users array in case dcb->or is zero because ffs(dcb->or) isused as index there.The 'or' argument of fabricate_dcb_output() must be interpreted as anumber of bit to set, not value.Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36923 Severity: Moderate CVSS3 score: 5.3

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36933 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:nsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().syzbot triggered various splats (see [0] and links) by a crafted GSOpacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols: ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDPNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the innerprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), callsskb_mac_gso_segment() to invoke inner protocol GSO handlers.nsh_gso_segment() does the following for the original skb beforecalling skb_mac_gso_segment() 1. reset skb->network_header 2. save the original skb->{mac_heaeder,mac_len} in a local variable 3. pull the NSH header 4. resets skb->mac_header 5. set up skb->mac_len and skb->protocol for the inner protocol.and does the following for the segmented skb 6. set ntohs(ETH_P_NSH) to skb->protocol 7. push the NSH header 8. restore skb->mac_header 9. set skb->mac_header + mac_len to skb->network_header 10. restore skb->mac_lenThere are two problems in 6-7 and 8-9. (a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev. Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skb_pull() in the first nsh_gso_segment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nsh_gso_segment(). (b) While restoring skb->{mac_header,network_header} in 8 & 9, nsh_gso_segment() does not assume that the data in the linear buffer is shifted. However, udp6_ufo_fragment() could shift the data and change skb->mac_header accordingly as demonstrated by syzbot. If this happens, even the restored skb->mac_header points to the middle of the outer header.It seems nsh_gso_segment() has never worked with outer headers so far.At the end of nsh_gso_segment(), the outer header must be restored forthe segmented skb, instead of the NSH header.To do that, let's calculate the outer header position relatively fromthe inner header and set skb->{data,mac_header,protocol} properly.[0]:BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline] ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222 __netdev_start_xmit include/linux/netdevice.h:4989 [inline] netdev_start_xmit include/linux/netdevice.h:5003 [inline] xmit_one net/core/dev.c:3547 [inline] dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351 dev_queue_xmit include/linux/netdevice.h:3171 [inline] packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276 packet_snd net/packet/af_packet.c:3081 [inline] packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x735/0xa10 net/socket.c:2191 __do_sys_sendto net/socket.c:2203 [inline] __se_sys_sendto net/socket.c:2199 [inline] __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at: slab_post_alloc_hook mm/slub.c:3819 [inline] slab_alloc_node mm/slub.c:3860 [inline] __do_kmalloc_node mm/slub.c:3980 [inline] __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582 __---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50232 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()In the ad7124_write_raw() function, parameter val can potentiallybe zero. This may lead to a division by zero when DIV_ROUND_CLOSEST()is called within ad7124_set_channel_odr(). The ad7124_write_raw()function is invoked through the sequence: iio_write_channel_raw() ->iio_write_channel_attribute() -> iio_channel_write(), with no checksin place to ensure val is non-zero.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-52304 Severity: Moderate CVSS3 score: 5.3

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.10.11, the Python parser parses newlines in chunk extensions incorrectly which can lead to request smuggling vulnerabilities under certain conditions. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or `AIOHTTP_NO_EXTENSIONS` is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.10.11 fixes the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2024-52615 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in Avahi-daemon, which relies on fixed source ports for wide-area DNS queries. This issue simplifies attacks where malicious DNS responses are injected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2024-52616 Severity: Moderate CVSS3 score: 5.3

Description: A flaw was found in the Avahi-daemon, where it initializes DNS transaction IDs randomly only once at startup, incrementing them sequentially after that. This predictable behavior facilitates DNS spoofing attacks, allowing attackers to guess transaction IDs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libavahi-client3 > 0-0 (version in image is 0.8-150400.7.23.1).

CVE-2024-56597 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix shift-out-of-bounds in dbSplitWhen dmt_budmin is less than zero, it causes errorsin the later stages. Added a check to return an error beforehandin dbAllocCtl itself.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56636 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:geneve: do not assume mac header is set in geneve_xmit_skb()We should not assume mac header is set in output path.Use skb_eth_hdr() instead of eth_hdr() to fix the issue.sysbot reported the following : WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 skb_mac_header include/linux/skbuff.h:3052 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 eth_hdr include/linux/if_ether.h:24 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit_skb drivers/net/geneve.c:898 [inline] WARNING: CPU: 0 PID: 11635 at include/linux/skbuff.h:3052 geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Modules linked in:CPU: 0 UID: 0 PID: 11635 Comm: syz.4.1423 Not tainted 6.12.0-syzkaller-10296-gaaf20f870da0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_mac_header include/linux/skbuff.h:3052 [inline] RIP: 0010:eth_hdr include/linux/if_ether.h:24 [inline] RIP: 0010:geneve_xmit_skb drivers/net/geneve.c:898 [inline] RIP: 0010:geneve_xmit+0x4c38/0x5730 drivers/net/geneve.c:1039Code: 21 c6 02 e9 35 d4 ff ff e8 a5 48 4c fb 90 0f 0b 90 e9 fd f5 ff ff e8 97 48 4c fb 90 0f 0b 90 e9 d8 f5 ff ff e8 89 48 4c fb 90 <0f> 0b 90 e9 41 e4 ff ff e8 7b 48 4c fb 90 0f 0b 90 e9 cd e7 ff ffRSP: 0018:ffffc90003b2f870 EFLAGS: 00010283RAX: 000000000000037a RBX: 000000000000ffff RCX: ffffc9000dc3d000RDX: 0000000000080000 RSI: ffffffff86428417 RDI: 0000000000000003RBP: ffffc90003b2f9f0 R08: 0000000000000003 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff88806603c000R13: 0000000000000000 R14: ffff8880685b2780 R15: 0000000000000e23FS: 00007fdc2deed6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b30a1dff8 CR3: 0000000056b8c000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] __dev_direct_xmit+0x58a/0x720 net/core/dev.c:4490 dev_direct_xmit include/linux/netdevice.h:3181 [inline] packet_xmit+0x1e4/0x360 net/packet/af_packet.c:285 packet_snd net/packet/af_packet.c:3146 [inline] packet_sendmsg+0x2700/0x5660 net/packet/af_packet.c:3178 sock_sendmsg_nosec net/socket.c:711 [inline] __sock_sendmsg net/socket.c:726 [inline] __sys_sendto+0x488/0x4f0 net/socket.c:2197 __do_sys_sendto net/socket.c:2204 [inline] __se_sys_sendto net/socket.c:2200 [inline] __x64_sys_sendto+0xe0/0x1c0 net/socket.c:2200 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56681 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - add error check in the ahash_hmac_init functionThe ahash_init functions may return fails. The ahash_hmac_init shouldnot return ok when ahash_init returns error. For an example, ahash_initwill return -ENOMEM when allocation memory is error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56756 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-pci: fix freeing of the HMB descriptor tableThe HMB descriptor table is sized to the maximum number of descriptorsthat could be used for a given device, but __nvme_alloc_host_mem couldbreak out of the loop earlier on memory allocation failure and end upusing less descriptors than planned for, which leads to an incorrectsize passed to dma_free_coherent.In practice this was not showing up because the number of descriptorstends to be low and the dma coherent allocator always allocates andfrees at least a page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-11083 Severity: Moderate CVSS3 score: 5.3

Description: A vulnerability has been found in GNU Binutils 2.45. The affected element is the function elf_swap_shdr in the library bfd/elfcode.h of the component Linker. The manipulation leads to heap-based buffer overflow. The attack must be carried out locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 9ca499644a21ceb3f946d1c179c38a83be084490. To fix this issue, it is recommended to deploy a patch. The code maintainer replied with "[f]ixed for 2.46".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-14524 Severity: Moderate CVSS3 score: 5.3

Description: When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transferperforms a cross-protocol redirect to a second URL that uses an IMAP, LDAP,POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the newtarget host.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-14819 Severity: Moderate CVSS3 score: 5.3

Description: When doing TLS related transfers with reused easy or multi handles andaltering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentallyreuse a CA store cached in memory for which the partial chain option wasreversed. Contrary to the user's wishes and expectations. This could makelibcurl find and accept a trust chain that it otherwise would not.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-15079 Severity: Moderate CVSS3 score: 5.3

Description: When doing SSH-based transfers using either SCP or SFTP, and setting theknown_hosts file, libcurl could still mistakenly accept connecting to hosts*not present* in the specified file if they were added as recognized in thelibssh *global* known_hosts file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-21653 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: cls_flow: validate TCA_FLOW_RSHIFT attributesyzbot found that TCA_FLOW_RSHIFT attribute was not validated.Right shitfing a 32bit integer is undefined for large shift values.UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024Workqueue: ipv6_addrconf addrconf_dad_workCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120 ubsan_epilogue lib/ubsan.c:231 [inline] __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468 flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329 tc_classify include/net/tc_wrapper.h:197 [inline] __tcf_classify net/sched/cls_api.c:1771 [inline] tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867 sfb_classify net/sched/sch_sfb.c:260 [inline] sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318 dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793 __dev_xmit_skb net/core/dev.c:3889 [inline] __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400 dev_queue_xmit include/linux/netdevice.h:3168 [inline] neigh_hh_output include/net/neighbour.h:523 [inline] neigh_output include/net/neighbour.h:537 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82 udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173 geneve_xmit_skb drivers/net/geneve.c:916 [inline] geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039 __netdev_start_xmit include/linux/netdevice.h:5002 [inline] netdev_start_xmit include/linux/netdevice.h:5011 [inline] xmit_one net/core/dev.c:3590 [inline] dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606 __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22058 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Fix memory accounting leak.Matt Dowling reported a weird UDP memory usage issue.Under normal operation, the UDP memory usage reported in /proc/net/sockstatremains close to zero. However, it occasionally spiked to 524,288 pagesand never dropped. Moreover, the value doubled when the application wasterminated. Finally, it caused intermittent packet drops.We can reproduce the issue with the script below [0]: 1. /proc/net/sockstat reports 0 pages # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 0 2. Run the script till the report reaches 524,288 # python3 test.py & sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 524288 <-- (INT_MAX + 1) >> PAGE_SHIFT 3. Kill the socket and confirm the number never drops # pkill python3 && sleep 5 # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 524288 4. (necessary since v6.0) Trigger proto_memory_pcpu_drain() # python3 test.py & sleep 1 && pkill python3 5. The number doubles # cat /proc/net/sockstat | grep UDP: UDP: inuse 1 mem 1048577The application set INT_MAX to SO_RCVBUF, which triggered an integeroverflow in udp_rmem_release().When a socket is close()d, udp_destruct_common() purges its receivequeue and sums up skb->truesize in the queue. This total is calculatedand stored in a local unsigned integer variable.The total size is then passed to udp_rmem_release() to adjust memoryaccounting. However, because the function takes a signed integerargument, the total size can wrap around, causing an overflow.Then, the released amount is calculated as follows: 1) Add size to sk->sk_forward_alloc. 2) Round down sk->sk_forward_alloc to the nearest lower multiple of PAGE_SIZE and assign it to amount. 3) Subtract amount from sk->sk_forward_alloc. 4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().When the issue occurred, the total in udp_destruct_common() was 2147484480(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().At 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and2) sets -2147479552 to amount. 3) reverts the wraparound, so we don'tsee a warning in inet_sock_destruct(). However, udp_memory_allocatedends up doubling at 4).Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves formemory_allocated"), memory usage no longer doubles immediately aftera socket is close()d because __sk_mem_reduce_allocated() caches theamount in udp_memory_per_cpu_fw_alloc. However, the next time a UDPsocket receives a packet, the subtraction takes effect, causing UDPmemory usage to double.This issue makes further memory allocation fail once the socket'ssk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packetdrops.To prevent this issue, let's use unsigned int for the calculation andcall sk_forward_alloc_add() only once for the small delta.Note that first_packet_length() also potentially has the same problem.[0]:from socket import *SO_RCVBUFFORCE = 33INT_MAX = (2 ** 31) - 1s = socket(AF_INET, SOCK_DGRAM)s.bind(('', 0))s.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)c = socket(AF_INET, SOCK_DGRAM)c.connect(s.getsockname())data = b'a' * 100while True: c.send(data)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-24294 Severity: Moderate CVSS3 score: 5.3

Description: The attack vector is a potential Denial of Service (DoS). The vulnerability is caused by an insufficient check on the length of a decompressed domain name within a DNS packet.An attacker can craft a malicious DNS packet containing a highly compressed domain name. When the resolv library parses such a packet, the name decompression process consumes a large amount of CPU resources, as the library does not limit the resulting length of the name.This resource consumption can cause the application thread to become unresponsive, resulting in a Denial of Service condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).

CVE-2025-37810 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: check that event count does not exceed event buffer lengthThe event count is read from register DWC3_GEVNTCOUNT.There is a check for the count being zero, but not for exceeding theevent buffer length.Check that event count does not exceed event buffer length,avoiding an out-of-bounds access when memcpy'ing the event.Crash log:Unable to handle kernel paging request at virtual address ffffffc0129be000pc : __memcpy+0x114/0x180lr : dwc3_check_event_buf+0xec/0x348x3 : 0000000000000030 x2 : 000000000000dfc4x1 : ffffffc0129be000 x0 : ffffff87aad60080Call trace:__memcpy+0x114/0x180dwc3_interrupt+0x24/0x34

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38022 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/core: Fix "KASAN: slab-use-after-free Read in ib_register_device" problemCall Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 strlen+0x93/0xa0 lib/string.c:420 __fortify_strlen include/linux/fortify-string.h:268 [inline] get_kobj_path_length lib/kobject.c:118 [inline] kobject_get_path+0x3f/0x2a0 lib/kobject.c:158 kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545 ib_register_device drivers/infiniband/core/device.c:1472 [inline] ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393 rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552 rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550 rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225 nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796 rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmsg+0x16d/0x220 net/socket.c:2652 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThis problem is similar to the problem that thecommit 1d6a9e7449e2 ("RDMA/core: Fix use-after-free when rename device name")fixes.The root cause is: the function ib_device_rename() renames the name withlock. But in the function kobject_uevent(), this name is accessed withoutlock protection at the same time.The solution is to add the lock protection when this name is accessed inthe function kobject_uevent().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38097 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:espintcp: remove encap socket caching to avoid reference leakThe current scheme for caching the encap socket can lead to referenceleaks when we try to delete the netns.The reference chain is: xfrm_state -> enacp_sk -> netnsSince the encap socket is a userspace socket, it holds a reference onthe netns. If we delete the espintcp state (through flush orindividual delete) before removing the netns, the reference on thesocket is dropped and the netns is correctly deleted. Otherwise, thenetns may not be reachable anymore (if all processes within the nshave terminated), so we cannot delete the xfrm state to drop itsreference on the socket.This patch results in a small (~2% in my tests) performanceregression.A GC-type mechanism could be added for the socket cache, to clearreferences if the state hasn't been used "recently", but it's a lotmore complex than just not caching the socket.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38157 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k_htc: Abort software beacon handling if disabledA malicious USB device can send a WMI_SWBA_EVENTID event from anath9k_htc-managed device before beaconing has been enabled. This causesa device-by-zero error in the driver, leading to either a crash or anout of bounds read.Prevent this by aborting the handling in ath9k_htc_swba() if beacons arenot enabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38173 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: marvell/cesa - Handle zero-length skcipher requestsDo not access random memory for zero-length skcipher requests.Just return 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38372 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix unsafe xarray access in implicit ODP handling__xa_store() and __xa_erase() were used without holding the proper lock,which led to a lockdep warning due to unsafe RCU usage. This patchreplaces them with xa_store() and xa_erase(), which perform the necessarylocking internally. ============================= WARNING: suspicious RCPU usage 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Not tainted ----------------------------- ./include/linux/xarray.h:1211 suspicious rcu_dereference_protected() usage! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 3 locks held by kworker/u136:0/219: at: process_one_work+0xbe4/0x15f0 process_one_work+0x75c/0x15f0 pagefault_mr+0x9a5/0x1390 [mlx5_ib] stack backtrace: CPU: 14 UID: 0 PID: 219 Comm: kworker/u136:0 Not tainted 6.14.0-rc7_for_upstream_debug_2025_03_18_15_01 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib] Call Trace: dump_stack_lvl+0xa8/0xc0 lockdep_rcu_suspicious+0x1e6/0x260 xas_create+0xb8a/0xee0 xas_store+0x73/0x14c0 __xa_store+0x13c/0x220 ? xa_store_range+0x390/0x390 ? spin_bug+0x1d0/0x1d0 pagefault_mr+0xcb5/0x1390 [mlx5_ib] ? _raw_spin_unlock+0x1f/0x30 mlx5_ib_eqe_pf_action+0x3be/0x2620 [mlx5_ib] ? lockdep_hardirqs_on_prepare+0x400/0x400 ? mlx5_ib_invalidate_range+0xcb0/0xcb0 [mlx5_ib] process_one_work+0x7db/0x15f0 ? pwq_dec_nr_in_flight+0xda0/0xda0 ? assign_work+0x168/0x240 worker_thread+0x57d/0xcd0 ? rescuer_thread+0xc40/0xc40 kthread+0x3b3/0x800 ? kthread_is_per_cpu+0xb0/0xb0 ? lock_downgrade+0x680/0x680 ? do_raw_spin_lock+0x12d/0x270 ? spin_bug+0x1d0/0x1d0 ? finish_task_switch.isra.0+0x284/0x9e0 ? lockdep_hardirqs_on_prepare+0x284/0x400 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork+0x2d/0x70 ? kthread_is_per_cpu+0xb0/0xb0 ret_from_fork_asm+0x11/0x20

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38462 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_{g2h,h2g} TOCTOUvsock_find_cid() and vsock_dev_do_ioctl() may race with module unload.transport_{g2h,h2g} may become NULL after the NULL check.Introduce vsock_transport_local_cid() to protect from a potentialnull-ptr-deref.KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_find_cid+0x47/0x90Call Trace: __vsock_bind+0x4b2/0x720 vsock_bind+0x90/0xe0 __sys_bind+0x14d/0x1e0 __x64_sys_bind+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]RIP: 0010:vsock_dev_do_ioctl.isra.0+0x58/0xf0Call Trace: __x64_sys_ioctl+0x12d/0x190 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38478 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix initialization of data for instructions that write to subdeviceSome Comedi subdevice instruction handlers are known to accessinstruction data elements beyond the first `insn->n` elements in somecases. The `do_insn_ioctl()` and `do_insnlist_ioctl()` functionsallocate at least `MIN_SAMPLES` (16) data elements to deal with this,but they do not initialize all of that. For Comedi instruction codesthat write to the subdevice, the first `insn->n` data elements arecopied from user-space, but the remaining elements are leftuninitialized. That could be a problem if the subdevice instructionhandler reads the uninitialized data. Ensure that the first`MIN_SAMPLES` elements are initialized before calling these instructionhandlers, filling the uncopied elements with 0. For`do_insnlist_ioctl()`, the same data buffer elements are used forhandling a list of instructions, so ensure the first `MIN_SAMPLES`elements are initialized for each instruction that writes to thesubdevice.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38480 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fix use of uninitialized data in insn_rw_emulate_bits()For Comedi `INSN_READ` and `INSN_WRITE` instructions on "digital"subdevices (subdevice types `COMEDI_SUBD_DI`, `COMEDI_SUBD_DO`, and`COMEDI_SUBD_DIO`), it is common for the subdevice driver not to have`insn_read` and `insn_write` handler functions, but to have an`insn_bits` handler function for handling Comedi `INSN_BITS`instructions. In that case, the subdevice's `insn_read` and/or`insn_write` function handler pointers are set to point to the`insn_rw_emulate_bits()` function by `__comedi_device_postconfig()`.For `INSN_WRITE`, `insn_rw_emulate_bits()` currently assumes that thesupplied `data[0]` value is a valid copy from user memory. It will atleast exist because `do_insnlist_ioctl()` and `do_insn_ioctl()` in"comedi_fops.c" ensure at lease `MIN_SAMPLES` (16) elements areallocated. However, if `insn->n` is 0 (which is allowable for`INSN_READ` and `INSN_WRITE` instructions, then `data[0]` may containuninitialized data, and certainly contains invalid data, possibly from adifferent instruction in the array of instructions handled by`do_insnlist_ioctl()`. This will result in an incorrect value beingwritten to the digital output channel (or to the digital input/outputchannel if configured as an output), and may be reflected in theinternal saved state of the channel.Fix it by returning 0 early if `insn->n` is 0, before reaching the codethat accesses `data[0]`. Previously, the function always returned 1 onsuccess, but it is supposed to be the number of data samples actuallyread or written up to `insn->n`, which is 0 in this case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38482 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das6402: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* IRQs 2,3,5,6,7, 10,11,15 are valid for "enhanced" mode */ if ((1 << it->options[1]) & 0x8cec) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test. Valid `it->options[1]` values that select the IRQwill be in the range [1,15]. The value 0 explicitly disables the use ofinterrupts.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38483 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: das16m1: Fix bit shift out of boundsWhen checking for a supported IRQ number, the following test is used: /* only irqs 2, 3, 4, 5, 6, 7, 10, 11, 12, 14, and 15 are valid */ if ((1 << it->options[1]) & 0xdcfc) {However, `it->options[i]` is an unchecked `int` value from userspace, sothe shift amount could be negative or out of bounds. Fix the test byrequiring `it->options[1]` to be within bounds before proceeding withthe original test.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38527 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix use-after-free in cifs_oplock_breakA race condition can occur in cifs_oplock_break() leading to ause-after-free of the cinode structure when unmounting: cifs_oplock_break() _cifsFileInfo_put(cfile) cifsFileInfo_put_final() cifs_sb_deactive() [last ref, start releasing sb] kill_sb() kill_anon_super() generic_shutdown_super() evict_inodes() dispose_list() evict() destroy_inode() call_rcu(&inode->i_rcu, i_callback) spin_lock(&cinode->open_file_lock) <- OK [later] i_callback() cifs_free_inode() kmem_cache_free(cinode) spin_unlock(&cinode->open_file_lock) <- UAF cifs_done_oplock_break(cinode) <- UAFThe issue occurs when umount has already released its reference to thesuperblock. When _cifsFileInfo_put() calls cifs_sb_deactive(), thisreleases the last reference, triggering the immediate cleanup of allinodes under RCU. However, cifs_oplock_break() continues to access thecinode after this point, resulting in use-after-free.Fix this by holding an extra reference to the superblock during theentire oplock break operation. This ensures that the superblock andits inodes remain valid until the oplock break completes.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38539 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Add down_write(trace_event_sem) when adding trace eventWhen a module is loaded, it adds trace events defined by the module. Itmay also need to modify the modules trace printk formats to replace enumnames with their values.If two modules are loaded at the same time, the adding of the event to theftrace_events list can corrupt the walking of the list in the code that ismodifying the printk format strings and crash the kernel.The addition of the event should take the trace_event_sem for write whileit adds the new event.Also add a lockdep_assert_held() on that semaphore in__trace_add_event_dirs() as it iterates the list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39788 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: exynos: Fix programming of HCI_UTRL_NEXUS_TYPEOn Google gs101, the number of UTP transfer request slots (nutrs) is 32,and in this case the driver ends up programming the UTRL_NEXUS_TYPEincorrectly as 0.This is because the left hand side of the shift is 1, which is of typeint, i.e. 31 bits wide. Shifting by more than that width results inundefined behaviour.Fix this by switching to the BIT() macro, which applies correct typecasting as required. This ensures the correct value is written toUTRL_NEXUS_TYPE (0xffffffff on gs101), and it also fixes a UBSAN shiftwarning: UBSAN: shift-out-of-bounds in drivers/ufs/host/ufs-exynos.c:1113:21 shift exponent 32 is too large for 32-bit type 'int'For consistency, apply the same change to the nutmrs / UTMRL_NEXUS_TYPEwrite.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39812 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:sctp: initialize more fields in sctp_v6_from_sk()syzbot found that sin6_scope_id was not properly initialized,leading to undefined behavior.Clear sin6_scope_id and sin6_flowinfo.BUG: KMSAN: uninit-value in __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 __sctp_v6_cmp_addr+0x887/0x8c0 net/sctp/ipv6.c:649 sctp_inet6_cmp_addr+0x4f2/0x510 net/sctp/ipv6.c:983 sctp_bind_addr_conflict+0x22a/0x3b0 net/sctp/bind_addr.c:390 sctp_get_port_local+0x21eb/0x2440 net/sctp/socket.c:8452 sctp_get_port net/sctp/socket.c:8523 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x710/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930 x64_sys_call+0x271d/0x3e20 arch/x86/include/generated/asm/syscalls_64.h:51 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xd9/0x210 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fLocal variable addr.i.i created at: sctp_get_port net/sctp/socket.c:8515 [inline] sctp_listen_start net/sctp/socket.c:8567 [inline] sctp_inet_listen+0x650/0xfd0 net/sctp/socket.c:8636 __sys_listen_socket net/socket.c:1912 [inline] __sys_listen net/socket.c:1927 [inline] __do_sys_listen net/socket.c:1932 [inline] __se_sys_listen net/socket.c:1930 [inline] __x64_sys_listen+0x343/0x4c0 net/socket.c:1930

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39927 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:ceph: fix race condition validating r_parent before applying stateAdd validation to ensure the cached parent directory inode matches thedirectory info in MDS replies. This prevents client-side race conditionswhere concurrent operations (e.g. rename) cause r_parent to become stalebetween request initiation and reply processing, which could lead toapplying state changes to incorrect directory inodes.[ idryomov: folded a kerneldoc fixup and a follow-up fix from Alex to move CEPH_CAP_PIN reference when r_parent is updated: When the parent directory lock is not held, req->r_parent can become stale and is updated to point to the correct inode. However, the associated CEPH_CAP_PIN reference was not being adjusted. The CEPH_CAP_PIN is a reference on an inode that is tracked for accounting purposes. Moving this pin is important to keep the accounting balanced. When the pin was not moved from the old parent to the new one, it created two problems: The reference on the old, stale parent was never released, causing a reference leak. A reference for the new parent was never acquired, creating the risk of a reference underflow later in ceph_mdsc_release_request(). This patch corrects the logic by releasing the pin from the old parent and acquiring it for the new parent when r_parent is switched. This ensures reference accounting stays balanced. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39964 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: af_alg - Disallow concurrent writes in af_alg_sendmsgIssuing two writes to the same af_alg socket is bogus as thedata will be interleaved in an unpredictable fashion. Furthermore,concurrent writes may create inconsistencies in the internalsocket state.Disallow this by adding a new ctx->write field that indiciatesexclusive ownership for writing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40003 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: mscc: ocelot: Fix use-after-free caused by cyclic delayed workThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()to cancel the cyclic delayed work item ocelot->stats_work. However,cancel_delayed_work() may fail to cancel the work item if it is alreadyexecuting. While destroy_workqueue() does wait for all pending work itemsin the work queue to complete before destroying the work queue, it cannotprevent the delayed work item from being rescheduled within theocelot_check_stats_work() function. This limitation exists because thedelayed work item is only enqueued into the work queue after its timerexpires. Before the timer expiration, destroy_workqueue() has no visibilityof this pending work item. Once the work queue appears empty,destroy_workqueue() proceeds with destruction. When the timer eventuallyexpires, the delayed work item gets queued again, leading to the followingwarning:workqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-statsWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0...RIP: 0010:__queue_work+0x875/0xaf0...RSP: 0018:ffff88806d108b10 EFLAGS: 00010086RAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027RDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88RBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2R10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000R13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0FS: 0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0Call Trace: ? kasan_report+0xc6/0xf0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? __pfx_delayed_work_timer_fn+0x10/0x10 call_timer_fn+0x25/0x1c0 __run_timer_base.part.0+0x3be/0x8c0 ? __pfx_delayed_work_timer_fn+0x10/0x10 ? rcu_sched_clock_irq+0xb06/0x27d0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? try_to_wake_up+0xb15/0x1960 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 tmigr_handle_remote_up+0x603/0x7e0 ? __pfx_tmigr_handle_remote_up+0x10/0x10 ? sched_balance_trigger+0x1c0/0x9f0 ? sched_tick+0x221/0x5a0 ? _raw_spin_lock_irq+0x80/0xe0 ? __pfx__raw_spin_lock_irq+0x10/0x10 ? tick_nohz_handler+0x339/0x440 ? __pfx_tmigr_handle_remote_up+0x10/0x10 __walk_groups.isra.0+0x42/0x150 tmigr_handle_remote+0x1f4/0x2e0 ? __pfx_tmigr_handle_remote+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 ? hrtimer_interrupt+0x322/0x780 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 ...The following diagram reveals the cause of the above warning:CPU 0 (remove) | CPU 1 (delayed work callback)mscc_ocelot_remove() | ocelot_deinit() | ocelot_check_stats_work() ocelot_stats_deinit() | cancel_delayed_work()| ... | queue_delayed_work() destroy_workqueue() | (wait a time) | __queue_work() //UAFThe above scenario actually constitutes a UAF vulnerability.The ocelot_stats_deinit() is only invoked when initializationfailure or resource destruction, so we must ensure that anydelayed work items cannot be rescheduled.Replace cancel_delayed_work() with disable_delayed_work_sync()to guarantee proper cancellation of the delayed work item andensure completion of any currently executing work before theworkqueue is deallocated.A deadlock concern was considered: ocelot_stats_deinit() is calledin a process context and is not holding any locks that the delayedwork item might also need. Therefore, the use of the _sync() variantis safe here.This bug was identified through static analysis. To reproduce theissue and validate the fix, I simulated ocelot-swit---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40027 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: fix double req put in p9_fd_cancelledSyzkaller reports a KASAN issue as below:general protection fault, probably for non-canonical address 0xfbd59c0000000021: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: maybe wild-memory-access in range [0xdead000000000108-0xdead00000000010f]CPU: 0 PID: 5083 Comm: syz-executor.2 Not tainted 6.1.134-syzkaller-00037-g855bd1d7d838 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:__list_del include/linux/list.h:114 [inline]RIP: 0010:__list_del_entry include/linux/list.h:137 [inline]RIP: 0010:list_del include/linux/list.h:148 [inline]RIP: 0010:p9_fd_cancelled+0xe9/0x200 net/9p/trans_fd.c:734Call Trace: p9_client_flush+0x351/0x440 net/9p/client.c:614 p9_client_rpc+0xb6b/0xc70 net/9p/client.c:734 p9_client_version net/9p/client.c:920 [inline] p9_client_create+0xb51/0x1240 net/9p/client.c:1027 v9fs_session_init+0x1f0/0x18f0 fs/9p/v9fs.c:408 v9fs_mount+0xba/0xcb0 fs/9p/vfs_super.c:126 legacy_get_tree+0x108/0x220 fs/fs_context.c:632 vfs_get_tree+0x8e/0x300 fs/super.c:1573 do_new_mount fs/namespace.c:3056 [inline] path_mount+0x6a6/0x1e90 fs/namespace.c:3386 do_mount fs/namespace.c:3399 [inline] __do_sys_mount fs/namespace.c:3607 [inline] __se_sys_mount fs/namespace.c:3584 [inline] __x64_sys_mount+0x283/0x300 fs/namespace.c:3584 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x6e/0xd8This happens because of a race condition between:- The 9p client sending an invalid flush request and later cleaning it up;- The 9p client in p9_read_work() canceled all pending requests. Thread 1 Thread 2 ... p9_client_create() ... p9_fd_create() ... p9_conn_create() ... // start Thread 2 INIT_WORK(&m->rq, p9_read_work); p9_read_work() ... p9_client_rpc() ... ... p9_conn_cancel() ... spin_lock(&m->req_lock); ... p9_fd_cancelled() ... ... spin_unlock(&m->req_lock); // status rewrite p9_client_cb(m->client, req, REQ_STATUS_ERROR) // first remove list_del(&req->req_list); ... spin_lock(&m->req_lock) ... // second remove list_del(&req->req_list); spin_unlock(&m->req_lock) ...Commit 74d6a5d56629 ("9p/trans_fd: Fix concurrency del of req_list inp9_fd_cancelled/p9_read_work") fixes a concurrency issue in the 9p filesystemclient where the req_list could be deleted simultaneously by bothp9_read_work and p9_fd_cancelled functions, but for the case where req->statusequals REQ_STATUS_RCVD.Update the check for req->status in p9_fd_cancelled to skip processing notjust received requests, but anything that is not SENT, as whateverchanged the state from SENT also removed the request from its list.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.[updated the check from status == RECV || status == ERROR to status != SENT]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40088 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()The hfsplus_strcasecmp() logic can trigger the issue:[ 117.317703][ T9855] ==================================================================[ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490[ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855[ 117.319577][ T9855][ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)[ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 117.319783][ T9855] Call Trace:[ 117.319785][ T9855] [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0[ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10[ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0[ 117.319816][ T9855] ? lock_release+0x4b/0x3e0[ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40[ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319842][ T9855] print_report+0x17e/0x7e0[ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0[ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0[ 117.319862][ T9855] ? __phys_addr+0xd3/0x180[ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319876][ T9855] kasan_report+0x147/0x180[ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490[ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490[ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10[ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0[ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470[ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10[ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10[ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510[ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10[ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10[ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510[ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0[ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120[ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890[ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10[ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0[ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80[ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10[ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100[ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150[ 117.320034][ T9855] __lookup_slow+0x297/0x3d0[ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10[ 117.320045][ T9855] ? down_read+0x1ad/0x2e0[ 117.320055][ T9855] lookup_slow+0x53/0x70[ 117.320065][ T9855] walk_component+0x2f0/0x430[ 117.320073][ T9855] path_lookupat+0x169/0x440[ 117.320081][ T9855] filename_lookup+0x212/0x590[ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10[ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290[ 117.320105][ T9855] ? getname_flags+0x1e5/0x540[ 117.320112][ T9855] user_path_at+0x3a/0x60[ 117.320117][ T9855] __x64_sys_umount+0xee/0x160[ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10[ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0[ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0[ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0[ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07[ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08[ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40183 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix metadata_dst leak __bpf_redirect_neigh_v{4,6}Cilium has a BPF egress gateway feature which forces outgoing K8s Podtraffic to pass through dedicated egress gateways which then SNAT thetraffic in order to interact with stable IPs outside the cluster.The traffic is directed to the gateway via vxlan tunnel in collect mdmode. A recent BPF change utilized the bpf_redirect_neigh() helper toforward packets after the arrival and decap on vxlan, which turned outover time that the kmalloc-256 slab usage in kernel was ever-increasing.The issue was that vxlan allocates the metadata_dst object and attachesit through a fake dst entry to the skb. The latter was never releasedthough given bpf_redirect_neigh() was merely setting the new dst entryvia skb_dst_set() without dropping an existing one first.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40322 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: bitblit: bound-check glyph index in bit_putcs*bit_putcs_aligned()/unaligned() derived the glyph pointer from thecharacter value masked by 0xff/0x1ff, which may exceed the actual font'sglyph count and read past the end of the built-in font array.Clamp the index to the actual glyph count before computing the address.This fixes a global out-of-bounds read reported by syzbot.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-47911 Severity: Moderate CVSS3 score: 5.3

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-47914 Severity: Moderate CVSS3 score: 5.3

Description: SSH Agent servers do not validate the size of messages when processing new identity requests, which may cause the program to panic if the message is malformed due to an out of bounds read.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-50181 Severity: Moderate CVSS3 score: 5.3

Description: urllib3 is a user-friendly HTTP client library for Python. Prior to 2.5.0, it is possible to disable redirects for all requests by instantiating a PoolManager and specifying retries in a way that disable redirects. By default, requests and botocore users are not affected. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. This issue has been patched in version 2.5.0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

CVE-2025-58181 Severity: Moderate CVSS3 score: 5.3

Description: SSH servers parsing GSSAPI authentication requests do not validate the number of mechanisms specified in the request, allowing an attacker to cause unbounded memory consumption.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-58190 Severity: Moderate CVSS3 score: 5.3

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-61984 Severity: Moderate CVSS3 score: 5.3

Description: ssh in OpenSSH before 10.1 allows control characters in usernames that originate from certain possibly untrusted sources, potentially leading to code execution when a ProxyCommand is used. The untrusted sources are the command line and %-sequence expansion of a configuration file. (A configuration file that provides a complete literal username is not categorized as an untrusted source.)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
openssh < 8.4p1-150300.3.57.1 (version in image is 8.4p1-150300.3.49.1).

CVE-2025-61985 Severity: Moderate CVSS3 score: 5.3

Description: ssh in OpenSSH before 10.1 allows the '\0' character in an ssh:// URI, potentially leading to code execution when a ProxyCommand is used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
openssh < 8.4p1-150300.3.57.1 (version in image is 8.4p1-150300.3.49.1).

CVE-2025-66418 Severity: Moderate CVSS3 score: 5.3

Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.24 and prior to 2.6.0, the number of links in the decompression chain was unbounded allowing a malicious server to insert a virtually unlimited number of compression steps leading to high CPU usage and massive memory allocation for the decompressed data. This vulnerability is fixed in 2.6.0.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-urllib3 > 0-0 (version in image is 2.0.7-150400.7.21.1).

CVE-2025-66471 Severity: Moderate CVSS3 score: 5.3

Description: urllib3 is a user-friendly HTTP client library for Python. Starting in version 1.0 and prior to 2.6.0, the Streaming API improperly handles highly compressed data. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. When streaming a compressed response, urllib3 can perform decoding or decompression based on the HTTP Content-Encoding header (e.g., gzip, deflate, br, or zstd). The library must read compressed data from the network and decompress it until the requested chunk size is met. Any resulting decompressed data that exceeds the requested amount is held in an internal buffer for the next read operation. The decompression logic could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This can result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-urllib3 > 0-0 (version in image is 2.0.7-150400.7.21.1).

CVE-2025-68315 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to detect potential corrupted nid in free_nid_listAs reported, on-disk footer.ino and footer.nid is the same andout-of-range, let's add sanity check on f2fs_alloc_nid() to detectany potential corruption in free_nid_list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68480 Severity: Moderate CVSS3 score: 5.3

Description: Marshmallow is a lightweight library for converting complex objects to and from simple Python datatypes. In versions from 3.0.0rc1 to before 3.26.2 and from 4.0.0 to before 4.1.2, Schema.load(data, many=True) is vulnerable to denial of service attacks. A moderately sized request can consume a disproportionate amount of CPU time. This issue has been patched in version 3.26.2 and 4.1.2.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-marshmallow > 0-0 (version in image is 3.20.2-150400.9.7.1).

CVE-2025-69225 Severity: Moderate CVSS3 score: 5.3

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below contain parser logic which allows non-ASCII decimals to be present in the Range header. There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-69226 Severity: Moderate CVSS3 score: 5.3

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below enable an attacker to ascertain the existence of absolute path components through the path normalization logic for static files meant to prevent path traversal. If an application uses web.static() (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. This issue is fixed in version 3.13.3.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-71093 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:e1000: fix OOB in e1000_tbi_should_accept()In e1000_tbi_should_accept() we read the last byte of the frame via'data[length - 1]' to evaluate the TBI workaround. If the descriptor-reported length is zero or larger than the actual RX buffer size, thisread goes out of bounds and can hit unrelated slab objects. The issueis observed from the NAPI receive path (e1000_clean_rx_irq):==================================================================BUG: KASAN: slab-out-of-bounds in e1000_tbi_should_accept+0x610/0x790Read of size 1 at addr ffff888014114e54 by task sshd/363CPU: 0 PID: 363 Comm: sshd Not tainted 5.18.0-rc1 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014Call Trace: dump_stack_lvl+0x5a/0x74 print_address_description+0x7b/0x440 print_report+0x101/0x200 kasan_report+0xc1/0xf0 e1000_tbi_should_accept+0x610/0x790 e1000_clean_rx_irq+0xa8c/0x1110 e1000_clean+0xde2/0x3c10 __napi_poll+0x98/0x380 net_rx_action+0x491/0xa20 __do_softirq+0x2c9/0x61d do_softirq+0xd1/0x120 __local_bh_enable_ip+0xfe/0x130 ip_finish_output2+0x7d5/0xb00 __ip_queue_xmit+0xe24/0x1ab0 __tcp_transmit_skb+0x1bcb/0x3340 tcp_write_xmit+0x175d/0x6bd0 __tcp_push_pending_frames+0x7b/0x280 tcp_sendmsg_locked+0x2e4f/0x32d0 tcp_sendmsg+0x24/0x40 sock_write_iter+0x322/0x430 vfs_write+0x56c/0xa60 ksys_write+0xd1/0x190 do_syscall_64+0x43/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xaeRIP: 0033:0x7f511b476b10Code: 73 01 c3 48 8b 0d 88 d3 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d f9 2b 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 8e 9b 01 00 48 89 04 24RSP: 002b:00007ffc9211d4e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 0000000000004024 RCX: 00007f511b476b10RDX: 0000000000004024 RSI: 0000559a9385962c RDI: 0000000000000003RBP: 0000559a9383a400 R08: fffffffffffffff0 R09: 0000000000004f00R10: 0000000000000070 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc9211d57f R14: 0000559a9347bde7 R15: 0000000000000003 Allocated by task 1: __kasan_krealloc+0x131/0x1c0 krealloc+0x90/0xc0 add_sysfs_param+0xcb/0x8a0 kernel_add_sysfs_param+0x81/0xd4 param_sysfs_builtin+0x138/0x1a6 param_sysfs_init+0x57/0x5b do_one_initcall+0x104/0x250 do_initcall_level+0x102/0x132 do_initcalls+0x46/0x74 kernel_init_freeable+0x28f/0x393 kernel_init+0x14/0x1a0 ret_from_fork+0x22/0x30The buggy address belongs to the object at ffff888014114000 which belongs to the cache kmalloc-2k of size 2048The buggy address is located 1620 bytes to the right of 2048-byte region [ffff888014114000, ffff888014114800]The buggy address belongs to the physical page:page:ffffea0000504400 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x14110head:ffffea0000504400 order:3 compound_mapcount:0 compound_pincount:0flags: 0x100000000010200(slab|head|node=0|zone=1)raw: 0100000000010200 0000000000000000 dead000000000001 ffff888013442000raw: 0000000000000000 0000000000080008 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detected==================================================================This happens because the TBI check unconditionally dereferences the lastbyte without validating the reported length first: u8 last_byte = *(data + length - 1);Fix by rejecting the frame early if the length is zero, or if it exceedsadapter->rx_buffer_len. This preserves the TBI workaround semantics forvalid frames and prevents touching memory beyond the RX buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-9390 Severity: Moderate CVSS3 score: 5.3

Description: A security flaw has been discovered in vim up to 9.1.1615. Affected by this vulnerability is the function main of the file src/xxd/xxd.c of the component xxd. The manipulation results in buffer overflow. The attack requires a local approach. The exploit has been released to the public and may be exploited. Upgrading to version 9.1.1616 addresses this issue. The patch is identified as eeef7c77436a78cd27047b0f5fa6925d56de3cb0. It is recommended to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2026-0915 Severity: Moderate CVSS3 score: 5.3

Description: Calling getnetbyaddr or getnetbyaddr_r with a configured nsswitch.conf that specifies the library's DNS backend for networks and queries for a zero-valued network in the GNU C Library version 2.0 to version 2.42 can leak stack contents to the configured DNS resolver.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glibc > 0-0 (version in image is 2.31-150300.95.1).

CVE-2023-53816 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: fix potential kgd_mem UAFskgd_mem pointers returned by kfd_process_device_translate_handle areonly guaranteed to be valid while p->mutex is held. As soon as the mutexis unlocked, another thread can free the BO.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40271 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:fs/proc: fix uaf in proc_readdir_de()Pde is erased from subdir rbtree through rb_erase(), but not set the nodeto EMPTY, which may result in uaf access. We should use RB_CLEAR_NODE()set the erased node to EMPTY, then pde_subdir_next() will return NULL toavoid uaf access.We found an uaf issue while using stress-ng testing, need to run testcasegetdent and tun in the same time. The steps of the issue is as follows:1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;3) continue to getdent process, then pde_subdir_next() will return pde(tun2) which is released, it will case uaf access.CPU 0 | CPU 1-------------------------------------------------------------------------traverse dir /proc/pid/net/dev_snmp6/ | unregister_netdevice(tun->dev) //tun3 tun2sys_getdents64() | iterate_dir() | proc_readdir() | proc_readdir_de() | snmp6_unregister_dev() pde_get(de); | proc_remove() read_unlock(&proc_subdir_lock); | remove_proc_subtree() | write_lock(&proc_subdir_lock); [time window] | rb_erase(&root->subdir_node, &parent->subdir); | write_unlock(&proc_subdir_lock); read_lock(&proc_subdir_lock); | next = pde_subdir_next(de); | pde_put(de); | de = next; //UAF |rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52493 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Drop chan lock before queuing buffersEnsure read and write locks for the channel are not taken in succession bydropping the read lock from parse_xfer_event() such that a callback givento client can potentially queue buffers and acquire the write lock in thatprocess. Any queueing of buffers should be done without channel read lockacquired as it can result in multiple locks and a soft lockup.[mani: added fixes tag and cc'ed stable]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52494 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Add alignment check for event ring read pointerThough we do check the event ring read pointer by "is_valid_ring_ptr"to make sure it is in the buffer range, but there is another risk thepointer may be not aligned. Since we are expecting event ring elementsare 128 bits(struct mhi_ring_element) aligned, an unaligned read pointercould lead to multiple issues like DoS or ring buffer memory corruption.So add a alignment check for event ring read pointer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53589 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don't trust firmware n_channelsIf the firmware sends us a corrupted MCC response withn_channels much larger than the command response can be,we might copy far too much (uninitialized) memory andeven crash if the n_channels is large enough to make itrun out of the one page allocated for the FW response.Fix that by checking the lengths. Doing a < comparisonwould be sufficient, but the firmware should be doingit correctly, so check more strictly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53756 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Fix crash due to uninitialized current_vmcsKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running asa nested hypervisor on top of Hyper-V. When MSR bitmap is updated,evmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to markthat the msr bitmap was changed.vmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr-> vmx_msr_bitmap_l01_changed which in the end calls this function. Thefunction checks for current_vmcs if it is null but the check isinsufficient because current_vmcs is not initialized. Because of this, thecode might incorrectly write to the structure pointed by current_vmcs valueleft by another task. Preemption is not disabled, the current task can bepreempted and moved to another CPU while current_vmcs is accessed multipletimes from evmcs_touch_msr_bitmap() which leads to crash.The manipulation of MSR bitmaps by callers happens only for vmcs01 so thesolution is to use vmx->vmcs01.vmcs instead of current_vmcs. BUG: kernel NULL pointer dereference, address: 0000000000000338 PGD 4e1775067 P4D 0 Oops: 0002 [#1] PREEMPT SMP NOPTI ... RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel] ... Call Trace: vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel] vmx_vcpu_create+0xe6/0x540 [kvm_intel] kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm] kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm] kvm_vm_ioctl+0x53f/0x790 [kvm] __x64_sys_ioctl+0x8a/0xc0 do_syscall_64+0x5c/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2201 Severity: Moderate CVSS3 score: 5.1

Description: A cross-privilege Spectre v2 vulnerability allows attackers to bypass all deployed mitigations, including the recent Fine(IBT), and to leak arbitrary Linux kernel memory on Intel systems.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-31142 Severity: Moderate CVSS3 score: 5.1

Description: Because of a logical error in XSA-407 (Branch Type Confusion), themitigation is not applied properly when it is intended to be used.XSA-434 (Speculative Return Stack Overflow) uses the sameinfrastructure, so is equally impacted.For more details, see: https://xenbits.xen.org/xsa/advisory-407.html https://xenbits.xen.org/xsa/advisory-434.html

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2024-36934 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:bna: ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don'tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nulinstead of memdup_user.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39476 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can't issuefrom raid5d().Current implementation in raid5d() has a weird dependence:1) md_check_recovery() from raid5d() must hold 'reconfig_mutex' to clear MD_SB_CHANGE_PENDING;2) raid5d() handles IO in a deadloop, until all IO are issued;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;This behaviour is introduce before v2.6, and for consequence, if othercontext hold 'reconfig_mutex', and md_check_recovery() can't updatesuper_block, then raid5d() will waste one cpu 100% by the deadloop, until'reconfig_mutex' is released.Refer to the implementation from raid1 and raid10, fix this problem byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when 'reconfig_mutex'is released. Meanwhile, the hang problem will be fixed as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39480 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22107 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: sja1105: fix kasan out-of-bounds warning in sja1105_table_delete_entry()There are actually 2 problems:- deleting the last element doesn't require the memmove of elements [i + 1, end) over it. Actually, element i+1 is out of bounds.- The memmove itself should move size - i - 1 elements, because the last element is out of bounds.The out-of-bounds element still remains out of bounds after beingaccessed, so the problem is only that we touch it, not that it becomesin active use. But I suppose it can lead to issues if the out-of-boundselement is part of an unmapped page.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38699 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Double-free fixWhen the bfad_im_probe() function fails during initialization, the memorypointed to by bfad->im is freed without setting bfad->im to NULL.Subsequently, during driver uninstallation, when the state machine entersthe bfad_sm_stopping state and calls the bfad_im_probe_undo() function,it attempts to free the memory pointed to by bfad->im again, therebytriggering a double-free vulnerability.Set bfad->im to NULL if probing fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39760 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: core: config: Prevent OOB read in SS endpoint companion parsingusb_parse_ss_endpoint_companion() checks descriptor type before length,enabling a potentially odd read outside of the buffer size.Fix this up by checking the size first before looking at any of thefields in the descriptor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39901 Severity: Moderate CVSS3 score: 5.1

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: remove read access to debugfs filesThe 'command' and 'netdev_ops' debugfs files are a legacy debugginginterface supported by the i40e driver since its early days by commit02e9c290814c ("i40e: debugfs interface").Both of these debugfs files provide a read handler which is mostly useless,and which is implemented with questionable logic. They both use a static256 byte buffer which is initialized to the empty string. In the case ofthe 'command' file this buffer is literally never used and simply wastesspace. In the case of the 'netdev_ops' file, the last command written issaved here.On read, the files contents are presented as the name of the devicefollowed by a colon and then the contents of their respective staticbuffer. For 'command' this will always be ": ". For 'netdev_ops',this will be ": ". But note the buffer isshared between all devices operated by this module. At best, it is mostlymeaningless information, and at worse it could be accessed simultaneouslyas there doesn't appear to be any locking mechanism.We have also recently received multiple reports for both read functionsabout their use of snprintf and potential overflow that could result inreading arbitrary kernel memory. For the 'command' file, this is definitelyimpossible, since the static buffer is always zero and never written to.For the 'netdev_ops' file, it does appear to be possible, if the usercarefully crafts the command input, it will be copied into the buffer,which could be large enough to cause snprintf to truncate, which thencauses the copy_to_user to read beyond the length of the buffer allocatedby kzalloc.A minimal fix would be to replace snprintf() with scnprintf() which wouldcap the return to the number of bytes written, preventing an overflow. Amore involved fix would be to drop the mostly useless static buffers,saving 512 bytes and modifying the read functions to stop needing those asinput.Instead, lets just completely drop the read access to these files. Theseare debug interfaces exposed as part of debugfs, and I don't believe thatdropping read access will break any script, as the provided output ispretty useless. You can find the netdev name through other more standardinterfaces, and the 'netdev_ops' interface can easily result in garbage ifyou issue simultaneous writes to multiple devices at once.In order to properly remove the i40e_dbg_netdev_ops_buf, we need torefactor its write function to avoid using the static buffer. Instead, usethe same logic as the i40e_dbg_command_write, with an allocated buffer.Update the code to use this instead of the static buffer, and ensure wefree the buffer on exit. This fixes simultaneous writes to 'netdev_ops' onmultiple devices, and allows us to remove the now unused static bufferalong with removing the read access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-64329 Severity: Moderate CVSS3 score: 5.1

Description: containerd is an open-source container runtime. Versions 1.7.28 and below, 2.0.0-beta.0 through 2.0.6, 2.1.0-beta.0 through 2.1.4, and 2.2.0-beta.0 through 2.2.0-rc.1 contain a bug in the CRI Attach implementation where a user can exhaust memory on the host due to goroutine leaks. This issue is fixed in versions 1.7.29, 2.0.7, 2.1.5 and 2.2.0. To workaround this vulnerability, users can set up an admission controller to control accesses to pods/attach resources.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd < 1.7.29-150000.128.1 (version in image is 1.7.27-150000.123.1).

CVE-2024-22231 Severity: Moderate CVSS3 score: 5.0

Description: Syndic cache directory creation is vulnerable to a directory traversal attack in salt project which can lead a malicious attacker to create an arbitrary directory on a Salt master.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
python3-salt > 0-0 (version in image is 3006.0-150400.8.83.6).

CVE-2024-40987 Severity: Moderate CVSS3 score: 5.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-20012 Severity: Moderate CVSS3 score: 4.9

Description: Incorrect behavior order for some Intel(R) Core(tm) Ultra Processors may allow an unauthenticated user to potentially enable information disclosure via physical access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38391 Severity: Moderate CVSS3 score: 4.9

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: do not index invalid pin_assignmentsA poorly implemented DisplayPort Alt Mode port partner can indicatethat its pin assignment capabilities are greater than the maximumvalue, DP_PIN_ASSIGN_F. In this case, calls to pin_assignment_showwill cause a BRK exception due to an out of bounds array access.Prevent for loop in pin_assignment_show from accessinginvalid values in pin_assignments by adding DP_PIN_ASSIGN_MAXvalue in typec_dp.h and using i < DP_PIN_ASSIGN_MAX as a loopcondition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-54770 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability has been identified in the GRUB2 bootloader's network module that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the net_set_vlan command is not properly unregistered when the network module is unloaded from memory. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2025-54771 Severity: Moderate CVSS3 score: 4.9

Description: A use-after-free vulnerability has been identified in the GNU GRUB (Grand Unified Bootloader). The flaw occurs because the file-closing process incorrectly retains a memory pointer, leaving an invalid reference to a file system structure. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2025-61662 Severity: Moderate CVSS3 score: 4.9

Description: A Use-After-Free vulnerability has been discovered in GRUB's gettext module. This flaw stems from a programming error where the gettext command remains registered in memory after its module is unloaded. An attacker can exploit this condition by invoking the orphaned command, causing the application to access a memory location that is no longer valid. An attacker could exploit this vulnerability to cause grub to crash, leading to a Denial of Service. Possible data integrity or confidentiality compromise is not discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2025-61663 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability has been identified in the GRUB2 bootloader's normal command that poses an immediate Denial of Service (DoS) risk. This flaw is a Use-after-Free issue, caused because the normal command is not properly unregistered when the module is unloaded. An attacker who can execute this command can force the system to access memory locations that are no longer valid. Successful exploitation leads directly to system instability, which can result in a complete crash and halt system availability. Impact on the data integrity and confidentiality is also not discarded.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2025-61664 Severity: Moderate CVSS3 score: 4.9

Description: A vulnerability in the GRUB2 bootloader has been identified in the normal module. This flaw, a memory Use After Free issue, occurs because the normal_exit command is not properly unregistered when its related module is unloaded. An attacker can exploit this condition by invoking the command after the module has been removed, causing the system to improperly access a previously freed memory location. This leads to a system crash or possible impacts in data confidentiality and integrity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2025-7039 Severity: Moderate CVSS3 score: 4.9

Description: A flaw was found in glib. An integer overflow during temporary file creation leads to an out-of-bounds memory access, allowing an attacker to potentially perform path traversal or access private temporary file content by creating symbolic links. This vulnerability allows a local attacker to manipulate file paths and access unauthorized data. The core issue stems from insufficient validation of file path lengths during temporary file operations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2022-48906 Severity: Moderate CVSS3 score: 4.8

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: Correctly set DATA_FIN timeout when number of retransmits is largeSyzkaller with UBSAN uncovered a scenario where a large number ofDATA_FIN retransmits caused a shift-out-of-bounds in the DATA_FINtimeout calculation:================================================================================UBSAN: shift-out-of-bounds in net/mptcp/protocol.c:470:29shift exponent 32 is too large for 32-bit type 'unsigned int'CPU: 1 PID: 13059 Comm: kworker/1:0 Not tainted 5.17.0-rc2-00630-g5fbf21c90c60 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Workqueue: events mptcp_workerCall Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 ubsan_epilogue+0xb/0x5a lib/ubsan.c:151 __ubsan_handle_shift_out_of_bounds.cold+0xb2/0x20e lib/ubsan.c:330 mptcp_set_datafin_timeout net/mptcp/protocol.c:470 [inline] __mptcp_retrans.cold+0x72/0x77 net/mptcp/protocol.c:2445 mptcp_worker+0x58a/0xa70 net/mptcp/protocol.c:2528 process_one_work+0x9df/0x16d0 kernel/workqueue.c:2307 worker_thread+0x95/0xe10 kernel/workqueue.c:2454 kthread+0x2f4/0x3b0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 ================================================================================This change limits the maximum timeout by limiting the size of theshift, which keeps all intermediate values in-bounds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-2283 Severity: Moderate CVSS3 score: 4.8

Description: A vulnerability was found in libssh, where the authentication check of the connecting client can be bypassed in the`pki_verify_data_signature` function in memory allocation problems. This issue may happen if there is insufficient memory or the memory usage is limited. The problem is caused by the return value `rc,` which is initialized to SSH_ERROR and later rewritten to save the return value of the function call `pki_key_check_hash_compatible.` The value of the variable is not changed between this point and the cryptographic verification. Therefore any error between them calls `goto error` returning SSH_OK.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.9.1).

CVE-2024-42367 Severity: Moderate CVSS3 score: 4.8

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In versions on the 3.10 branch prior to version 3.10.2, static routes which contain files with compressed variants (`.gz` or `.br` extension) are vulnerable to path traversal outside the root directory if those variants are symbolic links. The server protects static routes from path traversal outside the root directory when `follow_symlinks=False` (default). It does this by resolving the requested URL to an absolute path and then checking that path relative to the root. However, these checks are not performed when looking for compressed variants in the `FileResponse` class, and symbolic links are then automatically followed when performing the `Path.stat()` and `Path.open()` to send the file. Version 3.10.2 contains a patch for the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-4373 Severity: Moderate CVSS3 score: 4.8

Description: A flaw was found in GLib, which is vulnerable to an integer overflow in the g_string_insert_unichar() function. When the position at which to insert the character is large, the position will overflow, leading to a buffer underwrite.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2025-61661 Severity: Moderate CVSS3 score: 4.8

Description: A vulnerability has been identified in the GRUB (Grand Unified Bootloader) component. This flaw occurs because the bootloader mishandles string conversion when reading information from a USB device, allowing an attacker to exploit inconsistent length values. A local attacker can connect a maliciously configured USB device during the boot sequence to trigger this issue. A successful exploitation may lead GRUB to crash, leading to a Denial of Service. Data corruption may be also possible, although given the complexity of the exploit the impact is most likely limited.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2021-47577 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:io-wq: check for wq exit after adding new worker task_workWe check IO_WQ_BIT_EXIT before attempting to create a new worker, andwq exit cancels pending work if we have any. But it's possible to havea race between the two, where creation checks exit finding it not set,but we're in the process of exiting. The exit side will cancel pendingcreation task_work, but there's a gap where we add task_work after we'vecanceled existing creations at exit time.Fix this by checking the EXIT bit post adding the creation task_work.If it's set, run the same cancelation that exit does.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48785 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: use rcu-safe version of ipv6_get_lladdr()Some time ago 8965779d2c0e ("ipv6,mcast: always hold idev->lock before mca_lock")switched ipv6_get_lladdr() to __ipv6_get_lladdr(), which is rcu-unsafeversion. That was OK, because idev->lock was held for these codepaths.In 88e2ca308094 ("mld: convert ifmcaddr6 to RCU") these external locks wereremoved, so we probably need to restore the original rcu-safe call.Otherwise, we occasionally get a machine crashed/stalled with the followingin dmesg:[ 3405.966610][T230589] general protection fault, probably for non-canonical address 0xdead00000000008c: 0000 [#1] SMP NOPTI[ 3405.982083][T230589] CPU: 44 PID: 230589 Comm: kworker/44:3 Tainted: G O 5.15.19-cloudflare-2022.2.1 #1[ 3405.998061][T230589] Hardware name: SUPA-COOL-SERV[ 3406.009552][T230589] Workqueue: mld mld_ifc_work[ 3406.017224][T230589] RIP: 0010:__ipv6_get_lladdr+0x34/0x60[ 3406.025780][T230589] Code: 57 10 48 83 c7 08 48 89 e5 48 39 d7 74 3e 48 8d 82 38 ff ff ff eb 13 48 8b 90 d0 00 00 00 48 8d 82 38 ff ff ff 48 39 d7 74 22 <66> 83 78 32 20 77 1b 75 e4 89 ca 23 50 2c 75 dd 48 8b 50 08 48 8b[ 3406.055748][T230589] RSP: 0018:ffff94e4b3fc3d10 EFLAGS: 00010202[ 3406.065617][T230589] RAX: dead00000000005a RBX: ffff94e4b3fc3d30 RCX: 0000000000000040[ 3406.077477][T230589] RDX: dead000000000122 RSI: ffff94e4b3fc3d30 RDI: ffff8c3a31431008[ 3406.089389][T230589] RBP: ffff94e4b3fc3d10 R08: 0000000000000000 R09: 0000000000000000[ 3406.101445][T230589] R10: ffff8c3a31430000 R11: 000000000000000b R12: ffff8c2c37887100[ 3406.113553][T230589] R13: ffff8c3a39537000 R14: 00000000000005dc R15: ffff8c3a31431000[ 3406.125730][T230589] FS: 0000000000000000(0000) GS:ffff8c3b9fc80000(0000) knlGS:0000000000000000[ 3406.138992][T230589] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3406.149895][T230589] CR2: 00007f0dfea1db60 CR3: 000000387b5f2000 CR4: 0000000000350ee0[ 3406.162421][T230589] Call Trace:[ 3406.170235][T230589] [ 3406.177736][T230589] mld_newpack+0xfe/0x1a0[ 3406.186686][T230589] add_grhead+0x87/0xa0[ 3406.195498][T230589] add_grec+0x485/0x4e0[ 3406.204310][T230589] ? newidle_balance+0x126/0x3f0[ 3406.214024][T230589] mld_ifc_work+0x15d/0x450[ 3406.223279][T230589] process_one_work+0x1e6/0x380[ 3406.232982][T230589] worker_thread+0x50/0x3a0[ 3406.242371][T230589] ? rescuer_thread+0x360/0x360[ 3406.252175][T230589] kthread+0x127/0x150[ 3406.261197][T230589] ? set_kthread_struct+0x40/0x40[ 3406.271287][T230589] ret_from_fork+0x22/0x30[ 3406.280812][T230589] [ 3406.288937][T230589] Modules linked in: ... [last unloaded: kheaders][ 3406.476714][T230589] ---[ end trace 3525a7655f2f3b9e ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49052 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm: fix unexpected zeroed page mapping with zram swapTwo processes under CLONE_VM cloning, user process can be corrupted byseeing zeroed page unexpectedly. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage valid data swap_slot_free_notify delete zram entry swap_readpage zeroed(invalid) data pte_lock map the *zero data* to userspace pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return and next refault will read zeroed dataThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn'tincrease the refcount of swap slot at copy_mm so it couldn't catch upwhether it's safe or not to discard data from backing device. In thecase, only the lock it could rely on to synchronize swap slot freeing ispage table lock. Thus, this patch gets rid of the swap_slot_free_notifyfunction. With this patch, CPU A will see correct data. CPU A CPU B do_swap_page do_swap_page SWP_SYNCHRONOUS_IO path SWP_SYNCHRONOUS_IO path swap_readpage original data pte_lock map the original data swap_free swap_range_free bd_disk->fops->swap_slot_free_notify swap_readpage read zeroed data pte_unlock pte_lock if (!pte_same) goto out_nomap; pte_unlock return on next refault will see mapped data by CPU BThe concern of the patch would increase memory consumption since itcould keep wasted memory with compressed form in zram as well asuncompressed form in address space. However, most of cases of zram usesno readahead and do_swap_page is followed by swap_free so it will freethe compressed form from in zram quickly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49072 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: Restrict usage of GPIO chip irq members before initializationGPIO chip irq members are exposed before they could be completelyinitialized and this leads to race conditions.One such issue was observed for the gc->irq.domain variable whichwas accessed through the I2C interface in gpiochip_to_irq() beforeit could be initialized by gpiochip_add_irqchip(). This resulted inKernel NULL pointer dereference.Following are the logs for reference :-kernel: Call Trace:kernel: gpiod_to_irq+0x53/0x70kernel: acpi_dev_gpio_irq_get_by+0x113/0x1f0kernel: i2c_acpi_get_irq+0xc0/0xd0kernel: i2c_device_probe+0x28a/0x2a0kernel: really_probe+0xf2/0x460kernel: RIP: 0010:gpiochip_to_irq+0x47/0xc0To avoid such scenarios, restrict usage of GPIO chip irq members beforethey are completely initialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49578 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ip: Fix data-races around sysctl_ip_prot_sock.sysctl_ip_prot_sock is accessed concurrently, and there is always a chanceof data-race. So, all readers and writers need some basic protection toavoid load/store-tearing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49590 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:igmp: Fix data-races around sysctl_igmp_llm_reports.While reading sysctl_igmp_llm_reports, it can be changed concurrently.Thus, we need to add READ_ONCE() to its readers.This test can be packed into a helper, so such changes will be in thefollow-up series after net is merged into net-next. if (ipv4_is_local_multicast(pmc->multiaddr) && !READ_ONCE(net->ipv4.sysctl_igmp_llm_reports))

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50205 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext2: Add more validity checks for inode countsAdd checks verifying number of inodes stored in the superblock matchesthe number computed from number of inodes per group. Also verify we haveat least one block worth of inodes per group. This prevents crashes oncorrupted filesystems.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50350 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: iscsi: Fix a race condition between login_work and the login threadIn case a malicious initiator sends some random data immediately after alogin PDU; the iscsi_target_sk_data_ready() callback will schedule thelogin_work and, at the same time, the negotiation may end without clearingthe LOGIN_FLAGS_INITIAL_PDU flag (because no additional PDU exchanges arerequired to complete the login).The login has been completed but the login_work function will find theLOGIN_FLAGS_INITIAL_PDU flag set and will never stop from reschedulingitself; at this point, if the initiator drops the connection, theiscsit_conn structure will be freed, login_work will dereference a releasedsocket structure and the kernel crashes.BUG: kernel NULL pointer dereference, address: 0000000000000230PF: supervisor write access in kernel modePF: error_code(0x0002) - not-present pageWorkqueue: events iscsi_target_do_login_rx [iscsi_target_mod]RIP: 0010:_raw_read_lock_bh+0x15/0x30Call trace: iscsi_target_do_login_rx+0x75/0x3f0 [iscsi_target_mod] process_one_work+0x1e8/0x3c0Fix this bug by forcing login_work to stop after the login has beencompleted and the socket callbacks have been restored.Add a comment to clearify the return values of iscsi_target_do_login()

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50482 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/vt-d: Clean up si_domain in the init_dmars() error pathA splat from kmem_cache_destroy() was seen with a kernel prior tocommit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool")when there was a failure in init_dmars(), because the iommu_domaincache still had objects. While the mempool code is now gone, therestill is a leak of the si_domain memory if init_dmars() fails. Soclean up si_domain in the init_dmars() error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50561 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iio: fix memory leak in iio_device_register_eventset()When iio_device_register_sysfs_group() returns failed,iio_device_register_eventset() needs to free attrs array.Otherwise, kmemleak would scan & report memory leak as below:unreferenced object 0xffff88810a1cc3c0 (size 32): comm "100-i2c-vcnl302", pid 728, jiffies 4295052307 (age 156.027s) backtrace: __kmalloc+0x46/0x1b0 iio_device_register_eventset at drivers/iio/industrialio-event.c:541 __iio_device_register at drivers/iio/industrialio-core.c:1959 __devm_iio_device_register at drivers/iio/industrialio-core.c:2040

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50566 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: Fix device name leak when register device failed in add_mtd_device()There is a kmemleak when register device failed: unreferenced object 0xffff888101aab550 (size 8): comm "insmod", pid 3922, jiffies 4295277753 (age 925.408s) hex dump (first 8 bytes): 6d 74 64 30 00 88 ff ff mtd0.... backtrace: [<00000000bde26724>] __kmalloc_node_track_caller+0x4e/0x150 [<000000003c32b416>] kvasprintf+0xb0/0x130 [<000000001f7a8f15>] kobject_set_name_vargs+0x2f/0xb0 [<000000006e781163>] dev_set_name+0xab/0xe0 [<00000000e30d0c78>] add_mtd_device+0x4bb/0x700 [<00000000f3d34de7>] mtd_device_parse_register+0x2ac/0x3f0 [<00000000c0d88488>] 0xffffffffa0238457 [<00000000b40d0922>] 0xffffffffa02a008f [<0000000023d17b9d>] do_one_initcall+0x87/0x2a0 [<00000000770f6ca6>] do_init_module+0xdf/0x320 [<000000007b6768fe>] load_module+0x2f98/0x3330 [<00000000346bed5a>] __do_sys_finit_module+0x113/0x1b0 [<00000000674c2290>] do_syscall_64+0x35/0x80 [<000000004c6a8d97>] entry_SYSCALL_64_after_hwframe+0x46/0xb0If register device failed, should call put_device() to give up thereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50571 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: call __btrfs_remove_free_space_cache_locked on cache load failureNow that lockdep is staying enabled through our entire CI runs I startedseeing the following stack in generic/475------------[ cut here ]------------WARNING: CPU: 1 PID: 2171864 at fs/btrfs/discard.c:604 btrfs_discard_update_discardable+0x98/0xb0CPU: 1 PID: 2171864 Comm: kworker/u4:0 Not tainted 5.19.0-rc8+ #789Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014Workqueue: btrfs-cache btrfs_work_helperRIP: 0010:btrfs_discard_update_discardable+0x98/0xb0RSP: 0018:ffffb857c2f7bad0 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff8c85c605c200 RCX: 0000000000000001RDX: 0000000000000000 RSI: ffffffff86807c5b RDI: ffffffff868a831eRBP: ffff8c85c4c54000 R08: 0000000000000000 R09: 0000000000000000R10: ffff8c85c66932f0 R11: 0000000000000001 R12: ffff8c85c3899010R13: ffff8c85d5be4f40 R14: ffff8c85c4c54000 R15: ffff8c86114bfa80FS: 0000000000000000(0000) GS:ffff8c863bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2e7f168160 CR3: 000000010289a004 CR4: 0000000000370ee0Call Trace: __btrfs_remove_free_space_cache+0x27/0x30 load_free_space_cache+0xad2/0xaf0 caching_thread+0x40b/0x650 ? lock_release+0x137/0x2d0 btrfs_work_helper+0xf2/0x3e0 ? lock_is_held_type+0xe2/0x140 process_one_work+0x271/0x590 ? process_one_work+0x590/0x590 worker_thread+0x52/0x3b0 ? process_one_work+0x590/0x590 kthread+0xf0/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30This is the code ctl = block_group->free_space_ctl; discard_ctl = &block_group->fs_info->discard_ctl; lockdep_assert_held(&ctl->tree_lock);We have a temporary free space ctl for loading the free space cache inorder to avoid having allocations happening while we're loading thecache. When we hit an error we free it all up, however this also callsbtrfs_discard_update_discardable, which requiresblock_group->free_space_ctl->tree_lock to be held. However this is ourtemporary ctl so this lock isn't held. Fix this by calling__btrfs_remove_free_space_cache_locked instead so that we only clean upthe entries and do not mess with the discardable stats.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50578 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:class: fix possible memory leak in __class_register()If class_add_groups() returns error, the 'cp->subsys' need beunregister, and the 'cp' need be freed.We can not call kset_unregister() here, because the 'cls' willbe freed in callback function class_release() and it's alsofreed in caller's error path, it will cause double free.So fix this by calling kobject_del() and kfree_const(name) tocleanup kobject. Besides, call kfree() to free the 'cp'.Fault injection test can trigger this:unreferenced object 0xffff888102fa8190 (size 8): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 8 bytes): 70 6b 74 63 64 76 64 00 pktcdvd. backtrace: [<00000000e7c7703d>] __kmalloc_track_caller+0x1ae/0x320 [<000000005e4d70bc>] kstrdup+0x3a/0x70 [<00000000c2e5e85a>] kstrdup_const+0x68/0x80 [<000000000049a8c7>] kvasprintf_const+0x10b/0x190 [<0000000029123163>] kobject_set_name_vargs+0x56/0x150 [<00000000747219c9>] kobject_set_name+0xab/0xe0 [<0000000005f1ea4e>] __class_register+0x15c/0x49aunreferenced object 0xffff888037274000 (size 1024): comm "modprobe", pid 502, jiffies 4294906074 (age 49.296s) hex dump (first 32 bytes): 00 40 27 37 80 88 ff ff 00 40 27 37 80 88 ff ff .@'7.....@'7.... 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... backtrace: [<00000000151f9600>] kmem_cache_alloc_trace+0x17c/0x2f0 [<00000000ecf3dd95>] __class_register+0x86/0x49a

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-0160 Severity: Moderate CVSS3 score: 4.7

Description: A deadlock flaw was found in the Linux kernel's BPF subsystem. This flaw allows a local user to potentially crash the system.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-51767 Severity: Moderate CVSS3 score: 4.7

Description: OpenSSH through 10.0, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges. NOTE: this is disputed by the Supplier, who states "we do not consider it to be the application's responsibility to defend against platform architectural weaknesses."

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
openssh > 0-0 (version in image is 8.4p1-150300.3.49.1).

CVE-2023-52435 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: prevent mss overflow in skb_segment()Once again syzbot is able to crash the kernel in skb_segment() [1]GSO_BY_FRAGS is a forbidden value, but unfortunately the followingcomputation in skb_segment() can reach it quite easily : mss = mss * partial_segs;65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead toa bad final result.Make sure to limit segmentation so that the new mss value is smallerthan GSO_BY_FRAGS.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53__skb_gso_segment+0x339/0x710 net/core/gso.c:124skb_gso_segment include/net/gso.h:83 [inline]validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338dev_queue_xmit include/linux/netdevice.h:3134 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119sock_sendmsg_nosec net/socket.c:730 [inline]__sock_sendmsg+0xd5/0x180 net/socket.c:745__sys_sendto+0x255/0x340 net/socket.c:2190__do_sys_sendto net/socket.c:2202 [inline]__se_sys_sendto net/socket.c:2198 [inline]__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bRIP: 0033:0x7f8692032aa9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 d1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 83 e3 02 e9 fb ed ff ff e8 90 68 1c f9 48 8b 84 24 f8 00 00 00 48 8d 78 70 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 8a 21 00 00 48 8b 84 24 f8 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R0---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52587 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:IB/ipoib: Fix mcast list lockingReleasing the `priv->lock` while iterating the `priv->multicast_list` in`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` toremove the items while in the middle of iteration. If the mcast is removedwhile the lock was dropped, the for loop spins forever resulting in a hardlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel): Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below) -----------------------------------+----------------------------------- ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work) spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...) list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev) &priv->multicast_list, list) | ipoib_mcast_join(dev, mcast) | spin_unlock_irq(&priv->lock) | | spin_lock_irqsave(&priv->lock, flags) | list_for_each_entry_safe(mcast, tmcast, | &priv->multicast_list, list) | list_del(&mcast->list); | list_add_tail(&mcast->list, &remove_list) | spin_unlock_irqrestore(&priv->lock, flags) spin_lock_irq(&priv->lock) | | ipoib_mcast_remove_list(&remove_list) (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast, `priv->multicast_list` and we keep | remove_list, list) spinning on the `remove_list` of | >>> wait_for_completion(&mcast->done) the other thread which is blocked | and the list is still valid on | it's stack.)Fix this by keeping the lock held and changing to GFP_ATOMIC to preventeventual sleeps.Unfortunately we could not reproduce the lockup and confirm this fix butbased on the code review I think this fix should address such lockups.crash> bc 31PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2"-- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018--- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967crash> rx ff646f199a8c7e68ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.workcrash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000(empty)crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000crash> b 8PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0"-- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52589 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: rkisp1: Fix IRQ disable race issueIn rkisp1_isp_stop() and rkisp1_csi_disable() the driver masks theinterrupts and then apparently assumes that the interrupt handler won'tbe running, and proceeds in the stop procedure. This is not the case, asthe interrupt handler can already be running, which would lead to theISP being disabled while the interrupt handler handling a capturedframe.This brings up two issues: 1) the ISP could be powered off while theinterrupt handler is still running and accessing registers, leading toboard lockup, and 2) the interrupt handler code and the code thatdisables the streaming might do things that conflict.It is not clear to me if 2) causes a real issue, but 1) can be seen witha suitable delay (or printk in my case) in the interrupt handler,leading to board lockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52643 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iio: core: fix memleak in iio_device_register_sysfsWhen iio_device_register_sysfs_group() fails, we shouldfree iio_dev_opaque->chan_attr_group.attrs to preventpotential memleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52923 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: adapt set backend to use GC transaction APIUse the GC transaction API to replace the old and buggy gc API and thebusy mark approach.No set elements are removed from async garbage collection anymore,instead the _DEAD bit is set on so the set element is not visible fromlookup path anymore. Async GC enqueues transaction work that might beaborted and retried later.rbtree and pipapo set backends does not set on the _DEAD bit from thesync GC path since this runs in control plane path where mutex is held.In this case, set elements are deactivated, removed and then releasedvia RCU callback, sync GC never fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53292 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix NULL dereference on q->elevator in blk_mq_elv_switch_noneAfter grabbing q->sysfs_lock, q->elevator may become NULL because ofelevator switch.Fix the NULL dereference on q->elevator by checking it with lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53538 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: insert tree mod log move in push_node_leftThere is a fairly unlikely race condition in tree mod log rewind thatcan result in a kernel panic which has the following trace: [530.569] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.585] BTRFS critical (device sda3): unable to find logical 0 length 4096 [530.602] BUG: kernel NULL pointer dereference, address: 0000000000000002 [530.618] #PF: supervisor read access in kernel mode [530.629] #PF: error_code(0x0000) - not-present page [530.641] PGD 0 P4D 0 [530.647] Oops: 0000 [#1] SMP [530.654] CPU: 30 PID: 398973 Comm: below Kdump: loaded Tainted: G S O K 5.12.0-0_fbk13_clang_7455_gb24de3bdb045 #1 [530.680] Hardware name: Quanta Mono Lake-M.2 SATA 1HY9U9Z001G/Mono Lake-M.2 SATA, BIOS F20_3A15 08/16/2017 [530.703] RIP: 0010:__btrfs_map_block+0xaa/0xd00 [530.755] RSP: 0018:ffffc9002c2f7600 EFLAGS: 00010246 [530.767] RAX: ffffffffffffffea RBX: ffff888292e41000 RCX: f2702d8b8be15100 [530.784] RDX: ffff88885fda6fb8 RSI: ffff88885fd973c8 RDI: ffff88885fd973c8 [530.800] RBP: ffff888292e410d0 R08: ffffffff82fd7fd0 R09: 00000000fffeffff [530.816] R10: ffffffff82e57fd0 R11: ffffffff82e57d70 R12: 0000000000000000 [530.832] R13: 0000000000001000 R14: 0000000000001000 R15: ffffc9002c2f76f0 [530.848] FS: 00007f38d64af000(0000) GS:ffff88885fd80000(0000) knlGS:0000000000000000 [530.866] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [530.880] CR2: 0000000000000002 CR3: 00000002b6770004 CR4: 00000000003706e0 [530.896] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [530.912] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [530.928] Call Trace: [530.934] ? btrfs_printk+0x13b/0x18c [530.943] ? btrfs_bio_counter_inc_blocked+0x3d/0x130 [530.955] btrfs_map_bio+0x75/0x330 [530.963] ? kmem_cache_alloc+0x12a/0x2d0 [530.973] ? btrfs_submit_metadata_bio+0x63/0x100 [530.984] btrfs_submit_metadata_bio+0xa4/0x100 [530.995] submit_extent_page+0x30f/0x360 [531.004] read_extent_buffer_pages+0x49e/0x6d0 [531.015] ? submit_extent_page+0x360/0x360 [531.025] btree_read_extent_buffer_pages+0x5f/0x150 [531.037] read_tree_block+0x37/0x60 [531.046] read_block_for_search+0x18b/0x410 [531.056] btrfs_search_old_slot+0x198/0x2f0 [531.066] resolve_indirect_ref+0xfe/0x6f0 [531.076] ? ulist_alloc+0x31/0x60 [531.084] ? kmem_cache_alloc_trace+0x12e/0x2b0 [531.095] find_parent_nodes+0x720/0x1830 [531.105] ? ulist_alloc+0x10/0x60 [531.113] iterate_extent_inodes+0xea/0x370 [531.123] ? btrfs_previous_extent_item+0x8f/0x110 [531.134] ? btrfs_search_path_in_tree+0x240/0x240 [531.146] iterate_inodes_from_logical+0x98/0xd0 [531.157] ? btrfs_search_path_in_tree+0x240/0x240 [531.168] btrfs_ioctl_logical_to_ino+0xd9/0x180 [531.179] btrfs_ioctl+0xe2/0x2eb0This occurs when logical inode resolution takes a tree mod log sequencenumber, and then while backref walking hits a rewind on a busy nodewhich has the following sequence of tree mod log operations (numbersfilled in from a specific example, but they are somewhat arbitrary) REMOVE_WHILE_FREEING slot 532 REMOVE_WHILE_FREEING slot 531 REMOVE_WHILE_FREEING slot 530 ... REMOVE_WHILE_FREEING slot 0 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0 ADD slot 455 ADD slot 454 ADD slot 453 ... ADD slot 0 MOVE src slot 0 -> dst slot 456 nritems 533 REMOVE slot 455 REMOVE slot 454 REMOVE slot 453 ... REMOVE slot 0When this sequence gets applied via btrfs_tree_mod_log_rewind, itallocates a fresh rewind eb, and first inserts the correct key info forthe 533 elements, then overwrites the first 456 of them, then decrementsthe count by 456 via the add ops, then rewinds the move by doing amemmove from 456:988->0:532. We have never written anything past 532,---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53581 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Check for NOT_READY flag state after lockingCurrently the check for NOT_READY flag is performed before obtaining thenecessary lock. This opens a possibility for race condition when the flowis concurrently removed from unready_flows list by the workqueue task,which causes a double-removal from the list and a crash[0]. Fix the issueby moving the flag check inside the section protected byuplink_priv->unready_flows_lock mutex.[0]:[44376.389654] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP[44376.391665] CPU: 7 PID: 59123 Comm: tc Not tainted 6.4.0-rc4+ #1[44376.392984] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[44376.395342] RIP: 0010:mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core][44376.396857] Code: 00 48 8b b8 68 ce 02 00 e8 8a 4d 02 00 4c 8d a8 a8 01 00 00 4c 89 ef e8 8b 79 88 e1 48 8b 83 98 06 00 00 48 8b 93 90 06 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 83 90 06[44376.399167] RSP: 0018:ffff88812cc97570 EFLAGS: 00010246[44376.399680] RAX: dead000000000122 RBX: ffff8881088e3800 RCX: ffff8881881bac00[44376.400337] RDX: dead000000000100 RSI: ffff88812cc97500 RDI: ffff8881242f71b0[44376.401001] RBP: ffff88811cbb0940 R08: 0000000000000400 R09: 0000000000000001[44376.401663] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88812c944000[44376.402342] R13: ffff8881242f71a8 R14: ffff8881222b4000 R15: 0000000000000000[44376.402999] FS: 00007f0451104800(0000) GS:ffff88852cb80000(0000) knlGS:0000000000000000[44376.403787] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[44376.404343] CR2: 0000000000489108 CR3: 0000000123a79003 CR4: 0000000000370ea0[44376.405004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[44376.405665] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[44376.406339] Call Trace:[44376.406651] [44376.406939] ? die_addr+0x33/0x90[44376.407311] ? exc_general_protection+0x192/0x390[44376.407795] ? asm_exc_general_protection+0x22/0x30[44376.408292] ? mlx5e_tc_del_fdb_flow+0xb3/0x340 [mlx5_core][44376.408876] __mlx5e_tc_del_fdb_peer_flow+0xbc/0xe0 [mlx5_core][44376.409482] mlx5e_tc_del_flow+0x42/0x210 [mlx5_core][44376.410055] mlx5e_flow_put+0x25/0x50 [mlx5_core][44376.410529] mlx5e_delete_flower+0x24b/0x350 [mlx5_core][44376.411043] tc_setup_cb_reoffload+0x22/0x80[44376.411462] fl_reoffload+0x261/0x2f0 [cls_flower][44376.411907] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core][44376.412481] ? mlx5e_rep_indr_setup_ft_cb+0x160/0x160 [mlx5_core][44376.413044] tcf_block_playback_offloads+0x76/0x170[44376.413497] tcf_block_unbind+0x7b/0xd0[44376.413881] tcf_block_setup+0x17d/0x1c0[44376.414269] tcf_block_offload_cmd.isra.0+0xf1/0x130[44376.414725] tcf_block_offload_unbind+0x43/0x70[44376.415153] __tcf_block_put+0x82/0x150[44376.415532] ingress_destroy+0x22/0x30 [sch_ingress][44376.415986] qdisc_destroy+0x3b/0xd0[44376.416343] qdisc_graft+0x4d0/0x620[44376.416706] tc_get_qdisc+0x1c9/0x3b0[44376.417074] rtnetlink_rcv_msg+0x29c/0x390[44376.419978] ? rep_movs_alternative+0x3a/0xa0[44376.420399] ? rtnl_calcit.isra.0+0x120/0x120[44376.420813] netlink_rcv_skb+0x54/0x100[44376.421192] netlink_unicast+0x1f6/0x2c0[44376.421573] netlink_sendmsg+0x232/0x4a0[44376.421980] sock_sendmsg+0x38/0x60[44376.422328] ____sys_sendmsg+0x1d0/0x1e0[44376.422709] ? copy_msghdr_from_user+0x6d/0xa0[44376.423127] ___sys_sendmsg+0x80/0xc0[44376.423495] ? ___sys_recvmsg+0x8b/0xc0[44376.423869] __sys_sendmsg+0x51/0x90[44376.424226] do_syscall_64+0x3d/0x90[44376.424587] entry_SYSCALL_64_after_hwframe+0x46/0xb0[44376.425046] RIP: 0033:0x7f045134f887[44376.425403] Code: 0a 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53584 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this processThere are two states for ubifs writing pages:1. Dirty, Private2. Not Dirty, Not PrivateThe normal process cannot go to ubifs_releasepage() which means thereexists pages being private but not dirty. Reproducer[1] shows that itcould occur (which maybe related to [2]) with following process: PA PB PClock(page)[PA]ubifs_write_end attach_page_private // set Private __set_page_dirty_nobuffers // set Dirtyunlock(page)write_cache_pages[PA] lock(page) clear_page_dirty_for_io(page) // clear Dirty ubifs_writepage do_truncation[PB] truncate_setsize i_size_write(inode, newsize) // newsize = 0 i_size = i_size_read(inode) // i_size = 0 end_index = i_size >> PAGE_SHIFT if (page->index > end_index) goto out // jumpout:unlock(page) // Private, Not Dirty generic_fadvise[PC] lock(page) invalidate_inode_page try_to_release_page ubifs_releasepage ubifs_assert(c, 0) // bad assertion! unlock(page) truncate_pagecache[PB]Then we may get following assertion failed: UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]: UBIFS assert failed: 0, in fs/ubifs/file.c:1513 UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]: switched to read-only mode, error -22 CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308 Call Trace: dump_stack+0x13/0x1b ubifs_ro_mode+0x54/0x60 [ubifs] ubifs_assert_failed+0x4b/0x80 [ubifs] ubifs_releasepage+0x67/0x1d0 [ubifs] try_to_release_page+0x57/0xe0 invalidate_inode_page+0xfb/0x130 __invalidate_mapping_pages+0xb9/0x280 invalidate_mapping_pagevec+0x12/0x20 generic_fadvise+0x303/0x3c0 ksys_fadvise64_64+0x4c/0xb0[1] https://bugzilla.kernel.org/show_bug.cgi?id=215373[2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53602 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix memory leak in WMI firmware statsMemory allocated for firmware pdev, vdev and beacon statisticsare not released during rmmod.Fix it by calling ath11k_fw_stats_free() function before hardwareunregister.While at it, avoid calling ath11k_fw_stats_free() while processingthe firmware stats received in the WMI event because the local listis getting spliced and reinitialised and hence there are no elementsin the list after splicing.Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53604 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm integrity: call kmem_cache_destroy() in dm_integrity_init() error pathOtherwise the journal_io_cache will leak if dm_register_target() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53641 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: hif_usb: fix memory leak of remain_skbshif_dev->remain_skb is allocated and used exclusively inath9k_hif_usb_rx_stream(). It is implied that an allocated remain_skb isprocessed and subsequently freed (in error paths) only during the nextcall of ath9k_hif_usb_rx_stream().So, if the urbs are deallocated between those two calls due to the devicedeinitialization or suspend, it is possible that ath9k_hif_usb_rx_stream()is not called next time and the allocated remain_skb is leaked. Our localSyzkaller instance was able to trigger that.remain_skb makes sense when receiving two consecutive urbs which arelogically linked together, i.e. a specific data field from the first skbindicates a cached skb to be allocated, memcpy'd with some data andsubsequently processed in the next call to ath9k_hif_usb_rx_stream(). Urbsdeallocation supposedly makes that link irrelevant so we need to free thecached skb in those cases.Fix the leak by introducing a function to explicitly free remain_skb (ifit is not NULL) when the rx urbs have been deallocated. remain_skb is NULLwhen it has not been allocated at all (hif_dev struct is kzalloced) orwhen it has been processed in next call to ath9k_hif_usb_rx_stream().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53650 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: omapfb: lcd_mipid: Fix an error handling path in mipid_spi_probe()If 'mipid_detect()' fails, we must free 'md' to avoid a memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53662 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix memory leaks in ext4_fname_{setup_filename,prepare_lookup}If the filename casefolding fails, we'll be leaking memory from thefscrypt_name struct, namely from the 'crypto_buf.name' member.Make sure we free it in the error path on both ext4_fname_setup_filename()and ext4_fname_prepare_lookup() functions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53730 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk-iocost: use spin_lock_irqsave in adjust_inuse_and_calc_costadjust_inuse_and_calc_cost() use spin_lock_irq() and IRQ will be enabledwhen unlock. DEADLOCK might happen if we have held other locks and disabledIRQ before invoking it.Fix it by using spin_lock_irqsave() instead, which can keep IRQ stateconsistent with before when unlock. ================================ WARNING: inconsistent lock state 5.10.0-02758-g8e5f91fd772f #26 Not tainted -------------------------------- inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. kworker/2:3/388 [HC0[0]:SC0[0]:HE0:SE1] takes: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 {IN-HARDIRQ-W} state was registered at: __lock_acquire+0x3d7/0x1070 lock_acquire+0x197/0x4a0 __raw_spin_lock_irqsave _raw_spin_lock_irqsave+0x3b/0x60 bfq_idle_slice_timer_body bfq_idle_slice_timer+0x53/0x1d0 __run_hrtimer+0x477/0xa70 __hrtimer_run_queues+0x1c6/0x2d0 hrtimer_interrupt+0x302/0x9e0 local_apic_timer_interrupt __sysvec_apic_timer_interrupt+0xfd/0x420 run_sysvec_on_irqstack_cond sysvec_apic_timer_interrupt+0x46/0xa0 asm_sysvec_apic_timer_interrupt+0x12/0x20 irq event stamp: 837522 hardirqs last enabled at (837521): [] __raw_spin_unlock_irqrestore hardirqs last enabled at (837521): [] _raw_spin_unlock_irqrestore+0x3d/0x40 hardirqs last disabled at (837522): [] __raw_spin_lock_irq hardirqs last disabled at (837522): [] _raw_spin_lock_irq+0x43/0x50 softirqs last enabled at (835852): [] __do_softirq+0x558/0x8ec softirqs last disabled at (835845): [] asm_call_irq_on_stack+0xf/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&bfqd->lock); lock(&bfqd->lock); *** DEADLOCK *** 3 locks held by kworker/2:3/388: #0: ffff888107af0f38 ((wq_completion)kthrotld){+.+.}-{0:0}, at: process_one_work+0x742/0x13f0 #1: ffff8881176bfdd8 ((work_completion)(&td->dispatch_work)){+.+.}-{0:0}, at: process_one_work+0x777/0x13f0 #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: spin_lock_irq #2: ffff888118c00c28 (&bfqd->lock){?.-.}-{2:2}, at: bfq_bio_merge+0x141/0x390 stack backtrace: CPU: 2 PID: 388 Comm: kworker/2:3 Not tainted 5.10.0-02758-g8e5f91fd772f #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kthrotld blk_throtl_dispatch_work_fn Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x107/0x167 print_usage_bug valid_state mark_lock_irq.cold+0x32/0x3a mark_lock+0x693/0xbc0 mark_held_locks+0x9e/0xe0 __trace_hardirqs_on_caller lockdep_hardirqs_on_prepare.part.0+0x151/0x360 trace_hardirqs_on+0x5b/0x180 __raw_spin_unlock_irq _raw_spin_unlock_irq+0x24/0x40 spin_unlock_irq adjust_inuse_and_calc_cost+0x4fb/0x970 ioc_rqos_merge+0x277/0x740 __rq_qos_merge+0x62/0xb0 rq_qos_merge bio_attempt_back_merge+0x12c/0x4a0 blk_mq_sched_try_merge+0x1b6/0x4d0 bfq_bio_merge+0x24a/0x390 __blk_mq_sched_bio_merge+0xa6/0x460 blk_mq_sched_bio_merge blk_mq_submit_bio+0x2e7/0x1ee0 __submit_bio_noacct_mq+0x175/0x3b0 submit_bio_noacct+0x1fb/0x270 blk_throtl_dispatch_work_fn+0x1ef/0x2b0 process_one_work+0x83e/0x13f0 process_scheduled_works worker_thread+0x7e3/0xd80 kthread+0x353/0x470 ret_from_fork+0x1f/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53731 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netlink: fix potential deadlock in netlink_set_err()syzbot reported a possible deadlock in netlink_set_err() [1]A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQsfor netlink_lock_table()") in netlink_lock_table()This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()which were not covered by cited commit.[1]WARNING: possible irq lock inversion dependency detected6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not taintedsyz-executor.2/23011 just changed the state of lock:ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612but this lock was taken by another, SOFTIRQ-safe lock in the past: (&local->queue_stop_reason_lock){..-.}-{2:2}and interrupts could create inverse lock ordering between them.other info that might help us debug this: Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(nl_table_lock); local_irq_disable(); lock(&local->queue_stop_reason_lock); lock(nl_table_lock); lock(&local->queue_stop_reason_lock); *** DEADLOCK ***

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54013 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:interconnect: Fix locking for runpm vs reclaimFor cases where icc_bw_set() can be called in callbaths that coulddeadlock against shrinker/reclaim, such as runpm resume, we need todecouple the icc locking. Introduce a new icc_bw_lock for cases wherewe need to serialize bw aggregation and update to decouple that frompaths that require memory allocation such as node/link creation/destruction.Fixes this lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 6.2.0-rc8-debug+ #554 Not tainted ------------------------------------------------------ ring0/132 is trying to acquire lock: ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234 but task is already holding lock: ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #4 (dma_fence_map){++++}-{0:0}: __dma_fence_might_wait+0x74/0xc0 dma_resv_lockdep+0x1f4/0x2f4 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x80/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 topology_parse_cpu_capacity+0x8c/0x178 get_cpu_for_node+0x88/0xc4 parse_cluster+0x1b0/0x28c parse_cluster+0x8c/0x28c init_cpu_topology+0x168/0x188 smp_prepare_cpus+0x24/0xf8 kernel_init_freeable+0x18c/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #2 (fs_reclaim){+.+.}-{0:0}: __fs_reclaim_acquire+0x3c/0x48 fs_reclaim_acquire+0x54/0xa8 slab_pre_alloc_hook.constprop.0+0x40/0x25c __kmem_cache_alloc_node+0x60/0x1cc __kmalloc+0xd8/0x100 kzalloc.constprop.0+0x14/0x20 icc_node_create_nolock+0x4c/0xc4 icc_node_create+0x38/0x58 qcom_icc_rpmh_probe+0x1b8/0x248 platform_probe+0x70/0xc4 really_probe+0x158/0x290 __driver_probe_device+0xc8/0xe0 driver_probe_device+0x44/0x100 __driver_attach+0xf8/0x108 bus_for_each_dev+0x78/0xc4 driver_attach+0x2c/0x38 bus_add_driver+0xd0/0x1d8 driver_register+0xbc/0xf8 __platform_driver_register+0x30/0x3c qnoc_driver_init+0x24/0x30 do_one_initcall+0x104/0x2bc kernel_init_freeable+0x344/0x34c kernel_init+0x30/0x134 ret_from_fork+0x10/0x20 -> #1 (icc_lock){+.+.}-{3:3}: __mutex_lock+0xcc/0x3c8 mutex_lock_nested+0x30/0x44 icc_set_bw+0x88/0x2b4 _set_opp_bw+0x8c/0xd8 _set_opp+0x19c/0x300 dev_pm_opp_set_opp+0x84/0x94 a6xx_gmu_resume+0x18c/0x804 a6xx_pm_resume+0xf8/0x234 adreno_runtime_resume+0x2c/0x38 pm_generic_runtime_resume+0x30/0x44 __rpm_callback+0x15c/0x174 rpm_callback+0x78/0x7c rpm_resume+0x318/0x524 __pm_runtime_resume+0x78/0xbc adreno_load_gpu+0xc4/0x17c msm_open+0x50/0x120 drm_file_alloc+0x17c/0x228 drm_open_helper+0x74/0x118 drm_open+0xa0/0x144 drm_stub_open+0xd4/0xe4 chrdev_open+0x1b8/0x1e4 do_dentry_open+0x2f8/0x38c vfs_open+0x34/0x40 path_openat+0x64c/0x7b4 do_filp_open+0x54/0xc4 do_sys_openat2+0x9c/0x100 do_sys_open+0x50/0x7c __arm64_sys_openat+0x28/0x34 invoke_syscall+0x8c/0x128 el0_svc_common.constprop.0+0xa0/0x11c do_el0_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54134 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:autofs: fix memory leak of waitqueues in autofs_catatonic_modeSyzkaller reports a memory leak:BUG: memory leakunreferenced object 0xffff88810b279e00 (size 96): comm "syz-executor399", pid 3631, jiffies 4294964921 (age 23.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 08 9e 27 0b 81 88 ff ff ..........'..... 08 9e 27 0b 81 88 ff ff 00 00 00 00 00 00 00 00 ..'............. backtrace: [] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [] kmalloc include/linux/slab.h:576 [inline] [] autofs_wait+0x3fa/0x9a0 fs/autofs/waitq.c:378 [] autofs_do_expire_multi+0xa7/0x3e0 fs/autofs/expire.c:593 [] autofs_expire_multi+0x53/0x80 fs/autofs/expire.c:619 [] autofs_root_ioctl_unlocked+0x322/0x3b0 fs/autofs/root.c:897 [] autofs_root_ioctl+0x25/0x30 fs/autofs/root.c:910 [] vfs_ioctl fs/ioctl.c:51 [inline] [] __do_sys_ioctl fs/ioctl.c:870 [inline] [] __se_sys_ioctl fs/ioctl.c:856 [inline] [] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:856 [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [] entry_SYSCALL_64_after_hwframe+0x63/0xcdautofs_wait_queue structs should be freed if their wait_ctr becomes zero.Otherwise they will be lost.In this case an AUTOFS_IOC_EXPIRE_MULTI ioctl is done, then a newwaitqueue struct is allocated in autofs_wait(), its initial wait_ctrequals 2. After that wait_event_killable() is interrupted (it returns-ERESTARTSYS), so that 'wq->name.name == NULL' condition may be notsatisfied. Actually, this condition can be satisfied whenautofs_wait_release() or autofs_catatonic_mode() is called and, what isalso important, wait_ctr is decremented in those places. Upon the exit ofautofs_wait(), wait_ctr is decremented to 1. Then the unmounting processbegins: kill_sb calls autofs_catatonic_mode(), which should have freed thewaitqueues, but it only decrements its usage counter to zero which is nota correct behaviour.edit:imkThis description is of course not correct. The umount performed as a resultof an expire is a umount of a mount that has been automounted, it's not theautofs mount itself. They happen independently, usually after everythingmounted within the autofs file system has been expired away. If everythinghasn't been expired away the automount daemon can still exit leaving mountsin place. But expires done in both cases will result in a notification thatcalls autofs_wait_release() with a result status. The problem case is thesummary execution of of the automount daemon. In this case any waitingprocesses won't be woken up until either they are terminated or the mountis umounted.end edit: imkSo in catatonic mode we should free waitqueues which counter becomes zero.edit: imkInitially I was concerned that the calling of autofs_wait_release() andautofs_catatonic_mode() was not mutually exclusive but that can't be thecase (obviously) because the queue entry (or entries) is removed from thelist when either of these two functions are called. Consequently the waitentry will be freed by only one of these functions or by the woken processin autofs_wait() depending on the order of the calls.end edit: imk

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54158 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: don't free qgroup space unless specifiedBoris noticed in his simple quotas testing that he was getting a leakwith Sweet Tea's change to subvol create that stopped doing atransaction commit. This was just a side effect of that change.In the delayed inode code we have an optimization that will free extrareservations if we think we can pack a dir item into an already modifiedleaf. Previously this wouldn't be triggered in the subvolume createcase because we'd commit the transaction, it was still possible butmuch harder to trigger. It could actually be triggered if we did amkdir && subvol create with qgroups enabled.This occurs because in btrfs_insert_delayed_dir_index(), which getscalled when we're adding the dir item, we do the following: btrfs_block_rsv_release(fs_info, trans->block_rsv, bytes, NULL);if we're able to skip reserving space.The problem here is that trans->block_rsv points at the temporary blockrsv for the subvolume create, which has qgroup reservations in the blockrsv.This is a problem because btrfs_block_rsv_release() will do thefollowing: if (block_rsv->qgroup_rsv_reserved >= block_rsv->qgroup_rsv_size) { qgroup_to_release = block_rsv->qgroup_rsv_reserved - block_rsv->qgroup_rsv_size; block_rsv->qgroup_rsv_reserved = block_rsv->qgroup_rsv_size; }The temporary block rsv just has ->qgroup_rsv_reserved set,->qgroup_rsv_size == 0. The optimization inbtrfs_insert_delayed_dir_index() sets ->qgroup_rsv_reserved = 0. Thenlater on when we call btrfs_subvolume_release_metadata() which has btrfs_block_rsv_release(fs_info, rsv, (u64)-1, &qgroup_to_release); btrfs_qgroup_convert_reserved_meta(root, qgroup_to_release);qgroup_to_release is set to 0, and we do not convert the reservedmetadata space.The problem here is that the block rsv code has been unconditionallymessing with ->qgroup_rsv_reserved, because the main place this is usedis delalloc, and any time we call btrfs_block_rsv_release() we do itwith qgroup_to_release set, and thus do the proper accounting.The subvolume code is the only other code that uses the qgroupreservation stuff, but it's intermingled with the above optimization,and thus was getting its reservation freed out from underneath it andthus leaking the reserved space.The solution is to simply not mess with the qgroup reservations if wedon't have qgroup_to_release set. This works with the existing code asanything that messes with the delalloc reservations always haveqgroup_to_release set. This fixes the leak that Boris was observing.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54224 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix lockdep splat and potential deadlock after failure running delayed itemsWhen running delayed items we are holding a delayed node's mutex and thenwe will attempt to modify a subvolume btree to insert/update/delete thedelayed items. However if have an error during the insertions for example,btrfs_insert_delayed_items() may return with a path that has locked extentbuffers (a leaf at the very least), and then we attempt to release thedelayed node at __btrfs_run_delayed_items(), which requires taking thedelayed node's mutex, causing an ABBA type of deadlock. This was reportedby syzbot and the lockdep splat is the following: WARNING: possible circular locking dependency detected 6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted ------------------------------------------------------ syz-executor.2/13257 is trying to acquire lock: ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 but task is already holding lock: ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (btrfs-tree-00){++++}-{3:3}: __lock_release kernel/locking/lockdep.c:5475 [inline] lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781 up_write+0x79/0x580 kernel/locking/rwsem.c:1625 btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline] btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239 search_leaf fs/btrfs/ctree.c:1986 [inline] btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230 btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376 btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline] btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline] __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111 __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153 flush_space+0x269/0xe70 fs/btrfs/space-info.c:723 btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078 process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600 worker_thread+0xa63/0x1210 kernel/workqueue.c:2751 kthread+0x2b8/0x350 kernel/kthread.c:389 ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 -> #0 (&delayed_node->mutex){+.+.}-{3:3}: check_prev_add kernel/locking/lockdep.c:3142 [inline] check_prevs_add kernel/locking/lockdep.c:3261 [inline] validate_chain kernel/locking/lockdep.c:3876 [inline] __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144 lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761 __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603 __mutex_lock kernel/locking/mutex.c:747 [inline] mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799 __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256 btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline] __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156 btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276 btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988 vfs_fsync_range fs/sync.c:188 [inline] vfs_fsync fs/sync.c:202 [inline] do_fsync fs/sync.c:212 [inline] __do_sys_fsync fs/sync.c:220 [inline] __se_sys_fsync fs/sync.c:218 [inline] __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd other info that---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54226 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races around sk->sk_shutdown.KCSAN found a data race around sk->sk_shutdown where unix_release_sock()and unix_shutdown() update it under unix_state_lock(), OTOH unix_poll()and unix_dgram_poll() read it locklessly.We need to annotate the writes and reads with WRITE_ONCE() and READ_ONCE().BUG: KCSAN: data-race in unix_poll / unix_release_sockwrite to 0xffff88800d0f8aec of 1 bytes by task 264 on cpu 0: unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631 unix_release+0x59/0x80 net/unix/af_unix.c:1042 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1397 __fput+0x179/0x5e0 fs/file_table.c:321 ____fput+0x15/0x20 fs/file_table.c:349 task_work_run+0x116/0x1a0 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop kernel/entry/common.c:171 [inline] exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204 __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline] syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297 do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88800d0f8aec of 1 bytes by task 222 on cpu 1: unix_poll+0xa3/0x2a0 net/unix/af_unix.c:3170 sock_poll+0xcf/0x2b0 net/socket.c:1385 vfs_poll include/linux/poll.h:88 [inline] ep_item_poll.isra.0+0x78/0xc0 fs/eventpoll.c:855 ep_send_events fs/eventpoll.c:1694 [inline] ep_poll fs/eventpoll.c:1823 [inline] do_epoll_wait+0x6c4/0xea0 fs/eventpoll.c:2258 __do_sys_epoll_wait fs/eventpoll.c:2270 [inline] __se_sys_epoll_wait fs/eventpoll.c:2265 [inline] __x64_sys_epoll_wait+0xcc/0x190 fs/eventpoll.c:2265 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0x00 -> 0x03Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 222 Comm: dbus-broker Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54227 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix tags leak when shrink nr_hw_queuesAlthough we don't need to realloc set->tags[] when shrink nr_hw_queues,we need to free them. Or these tags will be leaked.How to reproduce:1. mount -t configfs configfs /mnt2. modprobe null_blk nr_devices=0 submit_queues=83. mkdir /mnt/nullb/nullb04. echo 1 > /mnt/nullb/nullb0/power5. echo 4 > /mnt/nullb/nullb0/submit_queues6. rmdir /mnt/nullb/nullb0In step 4, will alloc 9 tags (8 submit queues and 1 poll queue), thenin step 5, new_nr_hw_queues = 5 (4 submit queues and 1 poll queue).At last in step 6, only these 5 tags are freed, the other 4 tags leaked.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54254 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Don't leak a resource on eviction errorOn eviction errors other than -EMULTIHOP we were leaking a resource.Fix.v2:- Avoid yet another goto (Andi Shyti)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54297 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: fix memory leak after finding block group with super blocksAt exclude_super_stripes(), if we happen to find a block group that hassuper blocks mapped to it and we are on a zoned filesystem, we error outas this is not supposed to happen, indicating either a bug or maybe somememory corruption for example. However we are exiting the function withoutfreeing the memory allocated for the logical address of the super blocks.Fix this by freeing the logical address.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54307 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ptp_qoriq: fix memory leak in probe()Smatch complains that:drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()warn: 'base' from ioremap() not released.Fix this by revising the parameter from 'ptp_qoriq->base' to 'base'.This is only a bug if ptp_qoriq_init() returns on thefirst -ENODEV error path.For other error paths ptp_qoriq->base and base are the same.And this change makes the code more readable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0639 Severity: Moderate CVSS3 score: 4.7

Description: A denial of service vulnerability due to a deadlock was found in sctp_auto_asconf_init in net/sctp/socket.c in the Linux kernel's SCTP subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0641 Severity: Moderate CVSS3 score: 4.7

Description: A denial of service vulnerability was found in tipc_crypto_key_revoke in net/tipc/crypto.c in the Linux kernel's TIPC subsystem. This flaw allows guests with local user privileges to trigger a deadlock and potentially crash the system.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26989 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: hibernate: Fix level3 translation fault in swsusp_save()On arm64 machines, swsusp_save() faults if it attempts to accessMEMBLOCK_NOMAP memory ranges. This can be reproduced in QEMU using UEFIwhen booting with rodata=off debug_pagealloc=off and CONFIG_KFENCE=n: Unable to handle kernel paging request at virtual address ffffff8000000000 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=00000000eeb0b000 [ffffff8000000000] pgd=180000217fff9803, p4d=180000217fff9803, pud=180000217fff9803, pmd=180000217fff8803, pte=0000000000000000 Internal error: Oops: 0000000096000007 [#1] SMP Internal error: Oops: 0000000096000007 [#1] SMP Modules linked in: xt_multiport ipt_REJECT nf_reject_ipv4 xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c iptable_filter bpfilter rfkill at803x snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg dwmac_generic stmmac_platform snd_hda_codec stmmac joydev pcs_xpcs snd_hda_core phylink ppdev lp parport ramoops reed_solomon ip_tables x_tables nls_iso8859_1 vfat multipath linear amdgpu amdxcp drm_exec gpu_sched drm_buddy hid_generic usbhid hid radeon video drm_suballoc_helper drm_ttm_helper ttm i2c_algo_bit drm_display_helper cec drm_kms_helper drm CPU: 0 PID: 3663 Comm: systemd-sleep Not tainted 6.6.2+ #76 Source Version: 4e22ed63a0a48e7a7cff9b98b7806d8d4add7dc0 Hardware name: Greatwall GW-XXXXXX-XXX/GW-XXXXXX-XXX, BIOS KunLun BIOS V4.0 01/19/2021 pstate: 600003c5 (nZCv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : swsusp_save+0x280/0x538 lr : swsusp_save+0x280/0x538 sp : ffffffa034a3fa40 x29: ffffffa034a3fa40 x28: ffffff8000001000 x27: 0000000000000000 x26: ffffff8001400000 x25: ffffffc08113e248 x24: 0000000000000000 x23: 0000000000080000 x22: ffffffc08113e280 x21: 00000000000c69f2 x20: ffffff8000000000 x19: ffffffc081ae2500 x18: 0000000000000000 x17: 6666662074736420 x16: 3030303030303030 x15: 3038666666666666 x14: 0000000000000b69 x13: ffffff9f89088530 x12: 00000000ffffffea x11: 00000000ffff7fff x10: 00000000ffff7fff x9 : ffffffc08193f0d0 x8 : 00000000000bffe8 x7 : c0000000ffff7fff x6 : 0000000000000001 x5 : ffffffa0fff09dc8 x4 : 0000000000000000 x3 : 0000000000000027 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 000000000000004e Call trace: swsusp_save+0x280/0x538 swsusp_arch_suspend+0x148/0x190 hibernation_snapshot+0x240/0x39c hibernate+0xc4/0x378 state_store+0xf0/0x10c kobj_attr_store+0x14/0x24The reason is swsusp_save() -> copy_data_pages() -> page_is_saveable()-> kernel_page_present() assuming that a page is always present whencan_set_direct_map() is false (all of rodata_full,debug_pagealloc_enabled() and arm64_kfence_can_set_direct_map() false),irrespective of the MEMBLOCK_NOMAP ranges. Such MEMBLOCK_NOMAP regionsshould not be saved during hibernation.This problem was introduced by changes to the pfn_valid() logic incommit a7d9f306ba70 ("arm64: drop pfn_valid_within() and simplifypfn_valid()").Similar to other architectures, drop the !can_set_direct_map() check inkernel_page_present() so that page_is_savable() skips such pages.[catalin.marinas@arm.com: rework commit message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36286 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nfnetlink_queue: acquire rcu_read_lock() in instance_destroy_rcu()syzbot reported that nf_reinject() could be called without rcu_read_lock() :WARNING: suspicious RCU usage6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0 Not taintednet/netfilter/nfnetlink_queue.c:263 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 12 locks held by syz-executor.4/13427: #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:329 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2190 [inline] #0: ffffffff8e334f60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa86/0x1830 kernel/rcu/tree.c:2471 #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: nfqnl_flush net/netfilter/nfnetlink_queue.c:405 [inline] #1: ffff88801ca92958 (&inst->lock){+.-.}-{2:2}, at: instance_destroy_rcu+0x30/0x220 net/netfilter/nfnetlink_queue.c:172stack backtrace:CPU: 0 PID: 13427 Comm: syz-executor.4 Not tainted 6.9.0-rc7-syzkaller-02060-g5c1672705a1a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712 nf_reinject net/netfilter/nfnetlink_queue.c:323 [inline] nfqnl_reinject+0x6ec/0x1120 net/netfilter/nfnetlink_queue.c:397 nfqnl_flush net/netfilter/nfnetlink_queue.c:410 [inline] instance_destroy_rcu+0x1ae/0x220 net/netfilter/nfnetlink_queue.c:172 rcu_do_batch kernel/rcu/tree.c:2196 [inline] rcu_core+0xafd/0x1830 kernel/rcu/tree.c:2471 handle_softirqs+0x2d6/0x990 kernel/softirq.c:554 __do_softirq kernel/softirq.c:588 [inline] invoke_softirq kernel/softirq.c:428 [inline] __irq_exit_rcu+0xf4/0x1c0 kernel/softirq.c:637 irq_exit_rcu+0x9/0x30 kernel/softirq.c:649 instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline] sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36489 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tls: fix missing memory barrier in tls_initIn tls_init(), a write memory barrier is missing, and store-storereordering may cause NULL dereference in tls_{setsockopt,getsockopt}.CPU0 CPU1----- -----// In tls_init()// In tls_ctx_create()ctx = kzalloc()ctx->sk_proto = READ_ONCE(sk->sk_prot) -(1)// In update_sk_prot()WRITE_ONCE(sk->sk_prot, tls_prots) -(2) // In sock_common_setsockopt() READ_ONCE(sk->sk_prot)->setsockopt() // In tls_{setsockopt,getsockopt}() ctx->sk_proto->setsockopt() -(3)In the above scenario, when (1) and (2) are reordered, (3) can observethe NULL value of ctx->sk_proto, causing NULL dereference.To fix it, we rely on rcu_assign_pointer() which implies the releasebarrier semantic. By moving rcu_assign_pointer() after ctx->sk_proto isinitialized, we can ensure that ctx->sk_proto are visible whenchanging sk->sk_prot.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36924 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes thehbalock. Thus, lpfc_worker_wake_up() should not be called while holding thehbalock to avoid potential deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36952 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV's transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric. This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject. This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36954 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn't free the skb when it fails, so move'*buf = NULL' after __skb_linearize(), so that the skb can befreed on the err path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38544 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix seg fault in rxe_comp_queue_pktIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to theresp_pkts queue and then a decision is made whether to run the completertask inline or schedule it. Finally the skb is dereferenced to bump a 'hw'performance counter. This is wrong because if the completer task isalready running in a separate thread it may have already processed the skband freed it which can cause a seg fault. This has been observedinfrequently in testing at high scale.This patch fixes this by changing the order of enqueuing the packet untilafter the counter is accessed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38553 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: fec: remove .ndo_poll_controller to avoid deadlocksThere is a deadlock issue found in sungem driver, please refer to thecommit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoiddeadlocks"). The root cause of the issue is that netpoll is in atomiccontext and disable_irq() is called by .ndo_poll_controller interfaceof sungem driver, however, disable_irq() might sleep. After analyzingthe implementation of fec_poll_controller(), the fec driver should havethe same issue. Due to the fec driver uses NAPI for TX completions, the.ndo_poll_controller is unnecessary to be implemented in the fec driver,so fec_poll_controller() can be safely removed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38557 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Reload only IB representors upon lag disable/enableOn lag disable, the bond IB device along with all of itsrepresentors are destroyed, and then the slaves' representors get reloaded.In case the slave IB representor load fails, the eswitch error flowunloads all representors, including ethernet representors, where thenetdevs get detached and removed from lag bond. Such flow is inaccurateas the lag driver is not responsible for loading/unloading ethernetrepresentors. Furthermore, the flow described above begins by holdinglag lock to prevent bond changes during disable flow. However, whenreaching the ethernet representors detachment from lag, the lag lock isrequired again, triggering the following deadlock:Call trace:__switch_to+0xf4/0x148__schedule+0x2c8/0x7d0schedule+0x50/0xe0schedule_preempt_disabled+0x18/0x28__mutex_lock.isra.13+0x2b8/0x570__mutex_lock_slowpath+0x1c/0x28mutex_lock+0x4c/0x68mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]mlx5_disable_lag+0x130/0x138 [mlx5_core]mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev->lockmlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]devlink_nl_cmd_eswitch_set_doit+0xdc/0x180genl_family_rcv_msg_doit.isra.17+0xe8/0x138genl_rcv_msg+0xe4/0x220netlink_rcv_skb+0x44/0x108genl_rcv+0x40/0x58netlink_unicast+0x198/0x268netlink_sendmsg+0x1d4/0x418sock_sendmsg+0x54/0x60__sys_sendto+0xf4/0x120__arm64_sys_sendto+0x30/0x40el0_svc_common+0x8c/0x120do_el0_svc+0x30/0xa0el0_svc+0x20/0x30el0_sync_handler+0x90/0xb8el0_sync+0x160/0x180Thus, upon lag enable/disable, load and unload only the IB representorsof the slaves preventing the deadlock mentioned above.While at it, refactor the mlx5_esw_offloads_rep_load() function to havea static helper method for its internal logic, in symmetry with therepresentor unload design.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38590 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Modify the print level of CQE errorToo much print may lead to a panic in kernel. Change ibdev_err() toibdev_err_ratelimited(), and change the printing level of cqe dumpto debug level.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38591 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix deadlock on SRQ async events.xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/xa_erase_irq() to avoid deadlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38600 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: Fix deadlocks with kctl removals at disconnectionIn snd_card_disconnect(), we set card->shutdown flag at the beginning,call callbacks and do sync for card->power_ref_sleep waiters at theend. The callback may delete a kctl element, and this can lead to adeadlock when the device was in the suspended state. Namely:* A process waits for the power up at snd_power_ref_and_wait() in snd_ctl_info() or read/write() inside card->controls_rwsem.* The system gets disconnected meanwhile, and the driver tries to delete a kctl via snd_ctl_remove*(); it tries to take card->controls_rwsem again, but this is already locked by the above. Since the sleeper isn't woken up, this deadlocks.An easy fix is to wake up sleepers before processing the driverdisconnect callbacks but right after setting the card->shutdown flag.Then all sleepers will abort immediately, and the code flows again.So, basically this patch moves the wait_event() call at the righttiming. While we're at it, just to be sure, call wait_event_all()instead of wait_event(), although we don't use exclusive events onthis queue for now.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38602 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issues of ax25_devThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a referencecount leak issue of the object "ax25_dev".Memory leak issue in ax25_addr_ax25dev():The reference count of the object "ax25_dev" can be increased multipletimes in ax25_addr_ax25dev(). This will cause a memory leak.Memory leak issues in ax25_dev_device_down():The reference count of ax25_dev is set to 1 in ax25_dev_device_up() andthen increase the reference count when ax25_dev is added to ax25_dev_list.As a result, the reference count of ax25_dev is 2. But when the device isshutting down. The ax25_dev_device_down() drops the reference count onceor twice depending on if we goto unlock_put or not, which will causememory leak.As for the issue of ax25_addr_ax25dev(), it is impossible for one pointerto be on a list twice. So add a break in ax25_addr_ax25dev(). As for theissue of ax25_dev_device_down(), increase the reference count of ax25_devonce in ax25_dev_device_up() and decrease the reference count of ax25_devafter it is removed from the ax25_dev_list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38618 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: Set lower bound of start tick timeCurrently ALSA timer doesn't have the lower limit of the start ticktime, and it allows a very small size, e.g. 1 tick with 1ns resolutionfor hrtimer. Such a situation may lead to an unexpected RCU stall,where the callback repeatedly queuing the expire update, as reportedby fuzzer.This patch introduces a sanity check of the timer start tick time, sothat the system returns an error when a too small start size is set.As of this patch, the lower limit is hard-coded to 100us, which issmall enough but can still work somehow.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39276 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()Syzbot reports a warning as follows:============================================WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290Modules linked in:CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419Call Trace: ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375 generic_shutdown_super+0x136/0x2d0 fs/super.c:641 kill_block_super+0x44/0x90 fs/super.c:1675 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327[...]============================================This is because when finding an entry in ext4_xattr_block_cache_find(), ifext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grownin the __entry_find(), won't be put away, and eventually trigger the aboveissue in mb_cache_destroy() due to reference count leakage.So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39500 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:sock_map: avoid race between sock_map_close and sk_psock_putsk_psock_get will return NULL if the refcount of psock has gone to 0, whichwill happen when the last call of sk_psock_put is done. However,sk_psock_drop may not have finished yet, so the close callback will stillpoint to sock_map_close despite psock being NULL.This can be reproduced with a thread deleting an element from the sock map,while the second one creates a socket, adds it to the map and closes it.That will trigger the WARN_ON_ONCE:------------[ cut here ]------------WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701Modules linked in:CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870FS: 000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0Call Trace: unix_release+0x87/0xc0 net/unix/af_unix.c:1048 __sock_release net/socket.c:659 [inline] sock_close+0xbe/0x240 net/socket.c:1421 __fput+0x42b/0x8a0 fs/file_table.c:422 __do_sys_close fs/open.c:1556 [inline] __se_sys_close fs/open.c:1541 [inline] __x64_sys_close+0x7f/0x110 fs/open.c:1541 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fb37d618070Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7cRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Use sk_psock, which will only check that the pointer is not been set toNULL yet, which should only happen after the callbacks are restored. If,then, a reference can still be gotten, we may call sk_psock_stop and cancelpsock->work.As suggested by Paolo Abeni, reorder the condition so the control flow isless convoluted.After that change, the reproducer does not trigger the WARN_ON_ONCEanymore.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39501 Severity: Moderate CVSS3 score: 4.7

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39507 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash problem in concurrent scenarioWhen link status change, the nic driver need to notify the rocedriver to handle this event, but at this time, the roce drivermay uninit, then cause kernel crash.To fix the problem, when link status change, need to checkwhether the roce registered, and when uninit, need to wait linkupdate finish.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40965 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:i2c: lpi2c: Avoid calling clk_get_rate during transferInstead of repeatedly calling clk_get_rate for each transfer, lockthe clock rate and cache the value.A deadlock has been observed while adding tlv320aic32x4 audio codec tothe system. When this clock provider adds its clock, the clk mutex islocked already, it needs to access i2c, which in return needs the mutexfor clk_get_rate as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40966 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:tty: add the option to have a tty reject a new ldisc... and use it to limit the virtual terminals to just N_TTY. They arekind of special, and in particular, the "con_write()" routine violatesthe "writes cannot sleep" rule that some ldiscs rely on.This avoids the BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659when N_GSM has been attached to a virtual console, and gsmld_write()calls con_write() while holding a spinlock, and con_write() then triesto get the console lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40967 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:serial: imx: Introduce timeout when waiting on transmitter emptyBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potentialdeadlock.In case of the timeout, there is not much we can do, so we simply ignorethe transmitter state and optimistically try to continue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40980 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drop_monitor: replace spin_lock by raw_spin_locktrace_drop_common() is called with preemption disabled, and it acquiresa spin_lock. This is problematic for RT kernels because spin_locks aresleeping locks in this configuration, which causes the following splat:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47preempt_count: 1, expected: 0RCU nest depth: 2, expected: 25 locks held by rcuc/47/449: #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70 #4: ff1100086ee07520 (&data->lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290irq event stamp: 139909hardirqs last enabled at (139908): [] _raw_spin_unlock_irqrestore+0x63/0x80hardirqs last disabled at (139909): [] trace_drop_common.constprop.0+0x26d/0x290softirqs last enabled at (139892): [] __local_bh_enable_ip+0x103/0x170softirqs last disabled at (139898): [] rcu_cpu_kthread+0x93/0x1f0Preemption disabled at:[] rt_mutex_slowunlock+0xab/0x2e0CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022Call Trace: dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 __might_resched+0x21e/0x2f0 rt_spin_lock+0x5e/0x130 ? trace_drop_common.constprop.0+0xb5/0x290 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_drop_common.constprop.0+0xb5/0x290 ? preempt_count_sub+0x1c/0xd0 ? _raw_spin_unlock_irqrestore+0x4a/0x80 ? __pfx_trace_drop_common.constprop.0+0x10/0x10 ? rt_mutex_slowunlock+0x26a/0x2e0 ? skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_rt_mutex_slowunlock+0x10/0x10 ? skb_queue_purge_reason.part.0+0x1bf/0x230 trace_kfree_skb_hit+0x15/0x20 trace_kfree_skb+0xe9/0x150 kfree_skb_reason+0x7b/0x110 skb_queue_purge_reason.part.0+0x1bf/0x230 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10 ? mark_lock.part.0+0x8a/0x520...trace_drop_common() also disables interrupts, but this is a minor issuebecause we could easily replace it with a local_lock.Replace the spin_lock with raw_spin_lock to avoid sleeping in atomiccontext.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42079 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix NULL pointer dereference in gfs2_log_flushIn gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flushlock to provide exclusion against gfs2_log_flush().In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL beforedereferencing it. Otherwise, we could run into a NULL pointerdereference when outstanding glock work races with an unmount(glock_work_func -> run_queue -> do_xmote -> inode_go_sync ->gfs2_log_flush).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42115 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:jffs2: Fix potential illegal address access in jffs2_free_inodeDuring the stress testing of the jffs2 file system,the followingabnormal printouts were found:[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948[ 2430.649622] Mem abort info:[ 2430.649829] ESR = 0x96000004[ 2430.650115] EC = 0x25: DABT (current EL), IL = 32 bits[ 2430.650564] SET = 0, FnV = 0[ 2430.650795] EA = 0, S1PTW = 0[ 2430.651032] FSC = 0x04: level 0 translation fault[ 2430.651446] Data abort info:[ 2430.651683] ISV = 0, ISS = 0x00000004[ 2430.652001] CM = 0, WnR = 0[ 2430.652558] [0069696969696948] address between user and kernel address ranges[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33[ 2430.655008] Hardware name: linux,dummy-virt (DT)[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 2430.656142] pc : kfree+0x78/0x348[ 2430.656630] lr : jffs2_free_inode+0x24/0x48[ 2430.657051] sp : ffff800009eebd10[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000[ 2430.664217] Call trace:[ 2430.664528] kfree+0x78/0x348[ 2430.664855] jffs2_free_inode+0x24/0x48[ 2430.665233] i_callback+0x24/0x50[ 2430.665528] rcu_do_batch+0x1ac/0x448[ 2430.665892] rcu_core+0x28c/0x3c8[ 2430.666151] rcu_core_si+0x18/0x28[ 2430.666473] __do_softirq+0x138/0x3cc[ 2430.666781] irq_exit+0xf0/0x110[ 2430.667065] handle_domain_irq+0x6c/0x98[ 2430.667447] gic_handle_irq+0xac/0xe8[ 2430.667739] call_on_irq_stack+0x28/0x54The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field ofthe jffs_inode_info structure. It was found that all variables in the jffs_inode_infostructure were 5a5a5a5a, except for the first member sem. It is suspected that thesevariables are not initialized because they were set to 5a5a5a5a during memory testing,which is meant to detect uninitialized memory.The sem variable is initialized in thefunction jffs2_i_init_once, while other members are initialized inthe function jffs2_init_inode_info.The function jffs2_init_inode_info is called after iget_locked,but in the iget_locked function, the destroy_inode process is triggered,which releases the inode and consequently, the target member of the inodeis not initialized.In concurrent high pressure scenarios, iget_lockedmay enter the destroy_inode branch as described in the code.Since the destroy_inode functionality of jffs2 only releases the target,the fix method is to set target to NULL in jffs2_i_init_once.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44963 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not BUG_ON() when freeing tree block after errorWhen freeing a tree block, at btrfs_free_tree_block(), if we fail tocreate a delayed reference we don't deal with the error and just do aBUG_ON(). The error most likely to happen is -ENOMEM, and we have acomment mentioning that only -ENOMEM can happen, but that is not true,because in case qgroups are enabled any error returned frombtrfs_qgroup_trace_extent_post() (can be -EUCLEAN or anything returnedfrom btrfs_search_slot() for example) can be propagated back tobtrfs_free_tree_block().So stop doing a BUG_ON() and return the error to the callers and makethem abort the transaction to prevent leaking space. Syzbot wastriggering this, likely due to memory allocation failure injection.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45828 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:i3c: mipi-i3c-hci: Mask ring interrupts before ring stop requestBus cleanup path in DMA mode may trigger a RING_OP_STAT interrupt whenthe ring is being stopped. Depending on timing between ring stop requestcompletion, interrupt handler removal and code execution this may leadto a NULL pointer dereference in hci_dma_irq_handler() if it gets to runafter the io_data pointer is set to NULL in hci_dma_cleanup().Prevent this my masking the ring interrupts before ring stop request.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46678 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bonding: change ipsec_lock from spin lock to mutexIn the cited commit, bond->ipsec_lock is added to protect ipsec_list,hence xdo_dev_state_add and xdo_dev_state_delete are called insidethis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,"scheduling while atomic" will be triggered when changing bond'sactive slave.[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200[ 101.055726] Modules linked in:[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1[ 101.058760] Hardware name:[ 101.059434] Call Trace:[ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60[ 101.061275] __schedule_bug+0x4e/0x60[ 101.061682] __schedule+0x612/0x7c0[ 101.062078] ? __mod_timer+0x25c/0x370[ 101.062486] schedule+0x25/0xd0[ 101.062845] schedule_timeout+0x77/0xf0[ 101.063265] ? asm_common_interrupt+0x22/0x40[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10[ 101.064215] __wait_for_common+0x87/0x190[ 101.064648] ? usleep_range_state+0x90/0x90[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core][ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core][ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core][ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core][ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding][ 101.067738] ? kmalloc_trace+0x4d/0x350[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core][ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core][ 101.069312] bond_change_active_slave+0x392/0x900 [bonding][ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding][ 101.070454] __bond_opt_set+0xa6/0x430 [bonding][ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding][ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding][ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding][ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0[ 101.073033] vfs_write+0x2d8/0x400[ 101.073416] ? alloc_fd+0x48/0x180[ 101.073798] ksys_write+0x5f/0xe0[ 101.074175] do_syscall_64+0x52/0x110[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only calledfrom bond_change_active_slave, which requires holding the RTNL lock.And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm statexdo_dev_state_add and xdo_dev_state_delete APIs, which are in usercontext. So ipsec_lock doesn't have to be spin lock, change it tomutex, and thus the above issue can be resolved.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46750 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Add missing bridge lock to pci_bus_lock()One of the true positives that the cfg_access_lock lockdep effortidentified is this sequence: WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70 RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70 Call Trace: ? __warn+0x8c/0x190 ? pci_bridge_secondary_bus_reset+0x5d/0x70 ? report_bug+0x1f8/0x200 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? pci_bridge_secondary_bus_reset+0x5d/0x70 pci_reset_bus+0x1d8/0x270 vmd_probe+0x778/0xa10 pci_device_probe+0x95/0x120Where pci_reset_bus() users are triggering unlocked secondary bus resets.Ironically pci_bus_reset(), several calls down from pci_reset_bus(), usespci_bus_lock() before issuing the reset which locks everything *but* thebridge itself.For the same motivation as adding: bridge = pci_upstream_bridge(dev); if (bridge) pci_dev_lock(bridge);to pci_reset_function() for the "bus" and "cxl_bus" reset cases, addpci_dev_lock() for @bus->self to pci_bus_lock().[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47141 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pinmux: Use sequential access to access desc->pinmux dataWhen two client of the same gpio call pinctrl_select_state() for thesame functionality, we are seeing NULL pointer issue while accessingdesc->mux_owner.Let's say two processes A, B executing in pin_request() for the same pinand process A updates the desc->mux_usecount but not yet updated thedesc->mux_owner while process B see the desc->mux_usecount which gotupdated by A path and further executes strcmp and while accessingdesc->mux_owner it crashes with NULL pointer.Serialize the access to mux related setting with a mutex lock. cpu0 (process A) cpu1(process B)pinctrl_select_state() { pinctrl_select_state() { pin_request() { pin_request() { ... .... } else { desc->mux_usecount++; desc->mux_usecount && strcmp(desc->mux_owner, owner)) { if (desc->mux_usecount > 1) return 0; desc->mux_owner = owner; } }

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47679 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vfs: fix race between evice_inodes() and find_inode()&iput()Hi, allRecently I noticed a bug[1] in btrfs, after digged it intoand I believe it'a race in vfs.Let's assume there's a inode (ie ino 261) with i_count 1 iscalled by iput(), and there's a concurrent thread callinggeneric_shutdown_super().cpu0: cpu1:iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock()// note here: the inode 261// was still at sb list and hash list,// and I_FREEING|I_WILL_FREE was not been setbtrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEINGiput() ->spin_unlock(inode) ->spin_lock(inode) ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict()Now, we have two threads simultaneously evictingthe same inode, which may trigger the BUG(inode->i_state & I_CLEAR)statement both within clear_inode() and iput().To fix the bug, recheck the inode->i_count after holding i_lock.Because in the most scenarios, the first check is valid, andthe overhead of spin_lock() can be reduced.If there is any misunderstanding, please let me know, thanks.[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()return false when I reproduced the bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49868 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: fix a NULL pointer dereference when failed to start a new trasacntion[BUG]Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f[CAUSE]The allocation failure happens at the start_transaction() insideprepare_to_relocate(), and during the error handling we callunset_reloc_control(), which makes fs_info->balance_ctl to be NULL.Then we continue the error path cleanup in btrfs_balance() by callingreset_balance_state() which will call del_balance_item() to fully deletethe balance item in the root tree.However during the small window between set_reloc_contrl() andunset_reloc_control(), we can have a subvolume tree update and created areloc_root for that subvolume.Then we go into the final btrfs_commit_transaction() ofdel_balance_item(), and into btrfs_update_reloc_root() insidecommit_fs_roots().That function checks if fs_info->reloc_ctl is in the merge_reloc_treestage, but since fs_info->reloc_ctl is NULL, it results a NULL pointerdereference.[FIX]Just add extra check on fs_info->reloc_ctl insidebtrfs_update_reloc_root(), before checkingfs_info->reloc_ctl->merge_reloc_tree.That DEAD_RELOC_TREE handling is to prevent further modification to thereloc tree during merge stage, but since there is no reloc_ctl at all,we do not need to bother that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49933 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk_iocost: fix more out of bound shiftsRecently running UBSAN caught few out of bound shifts in theioc_forgive_debts() function:UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned longlong')...UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned longlong')...Call Trace:dump_stack_lvl+0xca/0x130__ubsan_handle_shift_out_of_bounds+0x22c/0x280? __lock_acquire+0x6441/0x7c10ioc_timer_fn+0x6cec/0x7750? blk_iocost_init+0x720/0x720? call_timer_fn+0x5d/0x470call_timer_fn+0xfa/0x470? blk_iocost_init+0x720/0x720__run_timer_base+0x519/0x700...Actual impact of this issue was not identified but I propose to fix theundefined behaviour.The proposed fix to prevent those out of bound shifts consist ofprecalculating exponent before using it the shift operations by takingmin value from the actual exponent and maximum possible number of bits.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50006 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix i_data_sem unlock order in ext4_ind_migrate()Fuzzing reports a possible deadlock in jbd2_log_wait_commit.This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to requiresynchronous updates because the file descriptor is opened with O_SYNC.This can lead to the jbd2_journal_stop() function callingjbd2_might_wait_for_commit(), potentially causing a deadlock if theEXT4_IOC_MIGRATE call races with a write(2) system call.This problem only arises when CONFIG_PROVE_LOCKING is enabled. In thiscase, the jbd2_might_wait_for_commit macro locks jbd2_handle in thejbd2_journal_stop function while i_data_sem is locked. This triggerslockdep because the jbd2_journal_start function might also lock the samejbd2_handle simultaneously.Found by Linux Verification Center (linuxtesting.org) with syzkaller.Rule: add

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50138 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use raw_spinlock_t in ringbufThe function __bpf_ringbuf_reserve is invoked from a tracepoint, whichdisables preemption. Using spinlock_t in this context can lead to a"sleep in atomic" warning in the RT variant. This issue is illustratedin the example below:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progspreempt_count: 1, expected: 0RCU nest depth: 1, expected: 1INFO: lockdep is turned off.Preemption disabled at:[] migrate_enable+0xc0/0x39cCPU: 7 PID: 556208 Comm: test_progs Tainted: GHardware name: Qualcomm SA8775P Ride (DT)Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180Switch the spinlock to raw_spinlock_t to avoid this error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50146 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Don't call cleanup on profile rollback failureWhen profile rollback fails in mlx5e_netdev_change_profile, the netdevprofile var is left set to NULL. Avoid a crash when unloading the driverby not calling profile->cleanup in such a case.This was encountered while testing, with the original trigger thatthe wq rescuer thread creation got interrupted (presumably due toCtrl+C-ing modprobe), which gets converted to ENOMEM (-12) bymlx5e_priv_init, the profile rollback also fails for the same reason(signal still active) so the profile is left as NULL, leading to a crashlater in _mlx5e_remove. [ 732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2) [ 734.525513] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12 [ 734.560153] workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR [ 734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12 [ 734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12 [ 745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008 [ 745.538222] #PF: supervisor read access in kernel mode [ 745.551290] Call Trace: [ 745.551590] [ 745.551866] ? __die+0x20/0x60 [ 745.552218] ? page_fault_oops+0x150/0x400 [ 745.555307] ? exc_page_fault+0x79/0x240 [ 745.555729] ? asm_exc_page_fault+0x22/0x30 [ 745.556166] ? mlx5e_remove+0x6b/0xb0 [mlx5_core] [ 745.556698] auxiliary_bus_remove+0x18/0x30 [ 745.557134] device_release_driver_internal+0x1df/0x240 [ 745.557654] bus_remove_device+0xd7/0x140 [ 745.558075] device_del+0x15b/0x3c0 [ 745.558456] mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core] [ 745.559112] mlx5_unregister_device+0x34/0x50 [mlx5_core] [ 745.559686] mlx5_uninit_one+0x46/0xf0 [mlx5_core] [ 745.560203] remove_one+0x4e/0xd0 [mlx5_core] [ 745.560694] pci_device_remove+0x39/0xa0 [ 745.561112] device_release_driver_internal+0x1df/0x240 [ 745.561631] driver_detach+0x47/0x90 [ 745.562022] bus_remove_driver+0x84/0x100 [ 745.562444] pci_unregister_driver+0x3b/0x90 [ 745.562890] mlx5_cleanup+0xc/0x1b [mlx5_core] [ 745.563415] __x64_sys_delete_module+0x14d/0x2f0 [ 745.563886] ? kmem_cache_free+0x1b0/0x460 [ 745.564313] ? lockdep_hardirqs_on_prepare+0xe2/0x190 [ 745.564825] do_syscall_64+0x6d/0x140 [ 745.565223] entry_SYSCALL_64_after_hwframe+0x4b/0x53 [ 745.565725] RIP: 0033:0x7f1579b1288b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50163 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Make sure internal and UAPI bpf_redirect flags don't overlapThe bpf_redirect_info is shared between the SKB and XDP redirect paths,and the two paths use the same numeric flag values in the ri->flagsfield (specifically, BPF_F_BROADCAST == BPF_F_NEXTHOP). This means thatif skb bpf_redirect_neigh() is used with a non-NULL params argument and,subsequently, an XDP redirect is performed using the samebpf_redirect_info struct, the XDP path will get confused and end upcrashing, which syzbot managed to trigger.With the stack-allocated bpf_redirect_info, the structure is no longershared between the SKB and XDP paths, so the crash doesn't happenanymore. However, different code paths using identically-numbered flagvalues in the same struct field still seems like a bit of a mess, sothis patch cleans that up by moving the flag definitions together andredefining the three flags in BPF_F_REDIRECT_INTERNAL to not overlapwith the flags used for XDP. It also adds a BUILD_BUG_ON() check to makesure the overlap is not re-introduced by mistake.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50184 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_pmem: Check device status before requesting flushIf a pmem device is in a bad status, the driver side could wait forhost ack forever in virtio_pmem_flush(), causing the system to hang.So add a status check in the beginning of virtio_pmem_flush() to returnearly if the device is not activated.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50275 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:arm64/sve: Discard stale CPU state when handling SVE trapsThe logic for handling SVE traps manipulates saved FPSIMD/SVE stateincorrectly, and a race with preemption can result in a task havingTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU stateis stale (e.g. with SVE traps enabled). This has been observed to resultin warnings from do_sve_acc() where SVE traps are not expected whileTIF_SVE is set:| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/The race can occur when the SVE trap handler is preempted before andafter manipulating the saved FPSIMD/SVE state, starting and ending onthe same CPU, e.g.| void do_sve_acc(unsigned long esr, struct pt_regs *regs)| {| // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled| // task->fpsimd_cpu is 0.| // per_cpu_ptr(&fpsimd_last_state, 0) is task.|| ...|| // Preempted; migrated from CPU 0 to CPU 1.| // TIF_FOREIGN_FPSTATE is set.|| get_cpu_fpsimd_context();|| if (test_and_set_thread_flag(TIF_SVE))| WARN_ON(1); /* SVE access shouldn't have trapped */|| sve_init_regs() {| if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {| ...| } else {| fpsimd_to_sve(current);| current->thread.fp_type = FP_STATE_SVE;| }| }|| put_cpu_fpsimd_context();|| // Preempted; migrated from CPU 1 to CPU 0.| // task->fpsimd_cpu is still 0| // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:| // - Stale HW state is reused (with SVE traps enabled)| // - TIF_FOREIGN_FPSTATE is cleared| // - A return to userspace skips HW state restore| }Fix the case where the state is not live and TIF_FOREIGN_FPSTATE is setby calling fpsimd_flush_task_state() to detach from the saved CPUstate. This ensures that a subsequent context switch will not reuse thestale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing thenew state to be reloaded from memory prior to a return to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53169 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: fix kernel crash while shutting down controllerThe nvme keep-alive operation, which executes at a periodic interval,could potentially sneak in while shutting down a fabric controller.This may lead to a race between the fabric controller admin queuedestroy code path (invoked while shutting down controller) and hw/hctxqueue dispatcher called from the nvme keep-alive async request queuingoperation. This race could lead to the kernel crash shown below:Call Trace: autoremove_wake_function+0x0/0xbc (unreliable) __blk_mq_sched_dispatch_requests+0x114/0x24c blk_mq_sched_dispatch_requests+0x44/0x84 blk_mq_run_hw_queue+0x140/0x220 nvme_keep_alive_work+0xc8/0x19c [nvme_core] process_one_work+0x200/0x4e0 worker_thread+0x340/0x504 kthread+0x138/0x140 start_kernel_thread+0x14/0x18While shutting down fabric controller, if nvme keep-alive request sneaksin then it would be flushed off. The nvme_keep_alive_end_io function isthen invoked to handle the end of the keep-alive operation whichdecrements the admin->q_usage_counter and assuming this is the last/onlyrequest in the admin queue then the admin->q_usage_counter becomes zero.If that happens then blk-mq destroy queue operation (blk_mq_destroy_queue()) which could be potentially running simultaneously on anothercpu (as this is the controller shutdown code path) would forwardprogress and deletes the admin queue. So, now from this point onwardwe are not supposed to access the admin queue resources. However theissue here's that the nvme keep-alive thread running hw/hctx queuedispatch operation hasn't yet finished its work and so it could stillpotentially access the admin queue resource while the admin queue hadbeen already deleted and that causes the above crash.The above kernel crash is regression caused due to changes implementedin commit a54a93d0e359 ("nvme: move stopping keep-alive intonvme_uninit_ctrl()"). Ideally we should stop keep-alive before destroying the admin queue and freeing the admin tagset so that it wouldn't sneakin during the shutdown operation. However we removed the keep alive stopoperation from the beginning of the controller shutdown code path in commita54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()")and added it under nvme_uninit_ctrl() which executes very late in theshutdown code path after the admin queue is destroyed and its tagset isremoved. So this change created the possibility of keep-alive sneaking inand interfering with the shutdown operation and causing observed kernelcrash.To fix the observed crash, we decided to move nvme_stop_keep_alive() fromnvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensurethat we don't forward progress and delete the admin queue until the keep-alive operation is finished (if it's in-flight) or cancelled and that wouldhelp contain the race condition explained above and hence avoid the crash.Moving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead ofadding nvme_stop_keep_alive() to the beginning of the controller shutdowncode path in nvme_stop_ctrl(), as was the case earlier before commita54a93d0e359 ("nvme: move stopping keep-alive into nvme_uninit_ctrl()"),would help save one callsite of nvme_stop_keep_alive().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53176 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: During unmount, ensure all cached dir instances drop their dentryThe unmount process (cifs_kill_sb() calling close_all_cached_dirs()) canrace with various cached directory operations, which ultimately resultsin dentries not being dropped and these kernel BUGs:BUG: Dentry ffff88814f37e358{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]VFS: Busy inodes after unmount of cifs (cifs)------------[ cut here ]------------kernel BUG at fs/super.c:661!This happens when a cfid is in the process of being cleaned up when, andhas been removed from the cfids->entries list, including:- Receiving a lease break from the server- Server reconnection triggers invalidate_all_cached_dirs(), which removes all the cfids from the list- The laundromat thread decides to expire an old cfid.To solve these problems, dropping the dentry is done in queued work donein a newly-added cfid_put_wq workqueue, and close_all_cached_dirs()flushes that workqueue after it drops all the dentries of which it'saware. This is a global workqueue (rather than scoped to a mount), butthe queued work is minimal.The final cleanup work for cleaning up a cfid is performed via workqueued in the serverclose_wq workqueue; this is done separate fromdropping the dentries so that close_all_cached_dirs() doesn't block onany server operations.Both of these queued works expect to invoked with a cfid reference anda tcon reference to avoid those objects from being freed while the workis ongoing.While we're here, add proper locking to close_all_cached_dirs(), andlocking around the freeing of cfid->dentry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53178 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Don't leak cfid when reconnect races with open_cached_diropen_cached_dir() may either race with the tcon reconnection even beforecompound_send_recv() or directly trigger a reconnection viaSMB2_open_init() or SMB_query_info_init().The reconnection process invokes invalidate_all_cached_dirs() viacifs_mark_open_files_invalid(), which removes all cfids from thecfids->entries list but doesn't drop a ref if has_lease isn't true. Thisresults in the currently-being-constructed cfid not being on the list,but still having a refcount of 2. It leaks if returned fromopen_cached_dir().Fix this by setting cfid->has_lease when the ref is actually taken; thecfid will not be used by other threads until it has a valid time.Addresses these kmemleaks:unreferenced object 0xffff8881090c4000 (size 1024): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 32 bytes): 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........"....... 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O..... backtrace (crc 6f58c20f): [] __kmalloc_cache_noprof+0x2be/0x350 [] open_cached_dir+0x993/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eunreferenced object 0xffff8881044fdcf8 (size 8): comm "bash", pid 1860, jiffies 4295126592 hex dump (first 8 bytes): 00 cc cc cc cc cc cc cc ........ backtrace (crc 10c106a9): [] __kmalloc_node_track_caller_noprof+0x363/0x480 [] kstrdup+0x36/0x60 [] open_cached_dir+0x9b0/0x1fb0 [] cifs_readdir+0x15a0/0x1d50 [] iterate_dir+0x28f/0x4b0 [] __x64_sys_getdents64+0xfd/0x200 [] do_syscall_64+0x95/0x1a0 [] entry_SYSCALL_64_after_hwframe+0x76/0x7eAnd addresses these BUG splats when unmounting the SMB filesystem:BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100Modules linked in:CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020RIP: 0010:umount_check+0xd0/0x100Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff <0f> 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41RSP: 0018:ffff88811cc27978 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20baeRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0Call Trace: d_walk+0x6a/0x530 shrink_dcache_for_umount+0x6a/0x200 generic_shutdown_super+0x52/0x2a0 kill_anon_super+0x22/0x40 cifs_kill_sb+0x159/0x1e0 deactivate_locked_super+0x66/0xe0 cleanup_mnt+0x140/0x210 task_work_run+0xfb/0x170 syscall_exit_to_user_mode+0x29f/0x2b0 do_syscall_64+0xa1/0x1a0 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7f23bfb93ae7Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53218 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix race in concurrent f2fs_stop_gc_threadIn my test case, concurrent calls to f2fs shutdown report the followingstack trace: Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85 Call Trace: ? show_regs+0x8b/0xa0 ? __die_body+0x26/0xa0 ? die_addr+0x54/0x90 ? exc_general_protection+0x24b/0x5c0 ? asm_exc_general_protection+0x26/0x30 ? kthread_stop+0x46/0x390 f2fs_stop_gc_thread+0x6c/0x110 f2fs_do_shutdown+0x309/0x3a0 f2fs_ioc_shutdown+0x150/0x1c0 __f2fs_ioctl+0xffd/0x2ac0 f2fs_ioctl+0x76/0xe0 vfs_ioctl+0x23/0x60 __x64_sys_ioctl+0xce/0xf0 x64_sys_call+0x2b1b/0x4540 do_syscall_64+0xa7/0x240 entry_SYSCALL_64_after_hwframe+0x76/0x7eThe root cause is a race condition in f2fs_stop_gc_thread() called fromdifferent f2fs shutdown paths: [CPU0] [CPU1] ---------------------- ----------------------- f2fs_stop_gc_thread f2fs_stop_gc_thread gc_th = sbi->gc_thread gc_th = sbi->gc_thread kfree(gc_th) sbi->gc_thread = NULL < gc_th != NULL > kthread_stop(gc_th->f2fs_gc_task) //UAFThe commit c7f114d864ac ("f2fs: fix to avoid use-after-free inf2fs_stop_gc_thread()") attempted to fix this issue by using a readsemaphore to prevent races between shutdown and remount threads, butit fails to prevent all race conditions.Fix it by converting to write lock of s_umount in f2fs_do_shutdown().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53224 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Move events notifier registration to be after device registrationMove pkey change work initialization and cleanup from device resourcesstage to notifier stage, since this is the stage which handles this workevents.Fix a race between the device deregistration and pkey change work by movingMLX5_IB_STAGE_DEVICE_NOTIFIER to be after MLX5_IB_STAGE_IB_REG in order toensure that the notifier is deregistered before the device during cleanup.Which ensures there are no works that are being executed after thedevice has already unregistered which can cause the panic below.BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 1 PID: 630071 Comm: kworker/1:2 Kdump: loaded Tainted: G W OE --------- --- 5.14.0-162.6.1.el9_1.x86_64 #1Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 02/27/2023Workqueue: events pkey_change_handler [mlx5_ib]RIP: 0010:setup_qp+0x38/0x1f0 [mlx5_ib]Code: ee 41 54 45 31 e4 55 89 f5 53 48 89 fb 48 83 ec 20 8b 77 08 65 48 8b 04 25 28 00 00 00 48 89 44 24 18 48 8b 07 48 8d 4c 24 16 <4c> 8b 38 49 8b 87 80 0b 00 00 4c 89 ff 48 8b 80 08 05 00 00 8b 40RSP: 0018:ffffbcc54068be20 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff954054494128 RCX: ffffbcc54068be36RDX: ffff954004934000 RSI: 0000000000000001 RDI: ffff954054494128RBP: 0000000000000023 R08: ffff954001be2c20 R09: 0000000000000001R10: ffff954001be2c20 R11: ffff9540260133c0 R12: 0000000000000000R13: 0000000000000023 R14: 0000000000000000 R15: ffff9540ffcb0905FS: 0000000000000000(0000) GS:ffff9540ffc80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 000000010625c001 CR4: 00000000003706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:mlx5_ib_gsi_pkey_change+0x20/0x40 [mlx5_ib]process_one_work+0x1e8/0x3c0worker_thread+0x50/0x3b0? rescuer_thread+0x380/0x380kthread+0x149/0x170? set_kthread_struct+0x50/0x50ret_from_fork+0x22/0x30Modules linked in: rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) mlx5_fwctl(OE) fwctl(OE) ib_uverbs(OE) mlx5_core(OE) mlxdevm(OE) ib_core(OE) mlx_compat(OE) psample mlxfw(OE) tls knem(OE) netconsole nfsv3 nfs_acl nfs lockd grace fscache netfs qrtr rfkill sunrpc intel_rapl_msr intel_rapl_common rapl hv_balloon hv_utils i2c_piix4 pcspkr joydev fuse ext4 mbcache jbd2 sr_mod sd_mod cdrom t10_pi sg ata_generic pci_hyperv pci_hyperv_intf hyperv_drm drm_shmem_helper drm_kms_helper hv_storvsc syscopyarea hv_netvsc sysfillrect sysimgblt hid_hyperv fb_sys_fops scsi_transport_fc hyperv_keyboard drm ata_piix crct10dif_pclmul crc32_pclmul crc32c_intel libata ghash_clmulni_intel hv_vmbus serio_raw [last unloaded: ib_core]CR2: 0000000000000000---[ end trace f6f8be4eae12f7bc ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-54683 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: IDLETIMER: Fix for possible ABBA deadlockDeletion of the last rule referencing a given idletimer may happen atthe same time as a read of its file in sysfs:| ======================================================| WARNING: possible circular locking dependency detected| 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted| ------------------------------------------------------| iptables/3303 is trying to acquire lock:| ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20|| but task is already holding lock:| ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v]|| which lock already depends on the new lock.A simple reproducer is:| #!/bin/bash|| while true; do| iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme"| done &| while true; do| cat /sys/class/xt_idletimer/timers/testme >/dev/null| doneAvoid this by freeing list_mutex right after deleting the element fromthe list, then continuing with the teardown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-55916 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Drivers: hv: util: Avoid accessing a ringbuffer not initialized yetIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer isfully initialized, we can hit the panic below:hv_utils: Registering HyperV Utility Driverhv_vmbus: registering driver hv_utils...BUG: kernel NULL pointer dereference, address: 0000000000000000CPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1RIP: 0010:hv_pkt_iter_first+0x12/0xd0Call Trace:... vmbus_recvpacket hv_kvp_onchannelcallback vmbus_on_event tasklet_action_common tasklet_action handle_softirqs irq_exit_rcu sysvec_hyperv_stimer0 asm_sysvec_hyperv_stimer0... kvp_register_done hvt_op_read vfs_read ksys_read __x64_sys_readThis can happen because the KVP/VSS channel callback can be invokedeven before the channel is fully opened:1) as soon as hv_kvp_init() -> hvutil_transport_init() creates/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately andregister itself to the driver by writing a message KVP_OP_REGISTER1 to thefile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) andreading the file for the driver's response, which is handled byhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().2) the problem with kvp_register_done() is that it can cause thechannel callback to be called even before the channel is fully opened,and when the channel callback is starting to run, util_probe()->vmbus_open() may have not initialized the ringbuffer yet, so thecallback can hit the panic of NULL pointer dereference.To reproduce the panic consistently, we can add a "ssleep(10)" for KVP in__vmbus_open(), just before the first hv_ringbuffer_init(), and then weunload and reload the driver hv_utils, and run the daemon manually withinthe 10 seconds.Fix the panic by reordering the steps in util_probe() so the char deventry used by the KVP or VSS daemon is not created until aftervmbus_open() has completed. This reordering prevents the race conditionfrom happening.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56568 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu: Defer probe of clients after smmu device boundNull pointer dereference occurs due to a race between smmudriver probe and client driver probe, when of_dma_configure()for client is called after the iommu_device_register() for smmu driverprobe has executed but before the driver_bound() for smmu driverhas been called.Following is how the race occurs:T1:Smmu device probe T2: Client device probereally_probe()arm_smmu_device_probe()iommu_device_register() really_probe() platform_dma_configure() of_dma_configure() of_dma_configure_id() of_iommu_configure() iommu_probe_device() iommu_init_device() arm_smmu_probe_device() arm_smmu_get_by_fwnode() driver_find_device_by_fwnode() driver_find_device() next_device() klist_next() /* null ptr assigned to smmu */ /* null ptr dereference while smmu->streamid_mask */driver_bound() klist_add_tail()When this null smmu pointer is dereferenced later inarm_smmu_probe_device, the device crashes.Fix this by deferring the probe of the client deviceuntil the smmu device has bound to the arm smmu driver.[will: Add comment]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56587 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:leds: class: Protect brightness_show() with led_cdev->led_access mutexThere is NULL pointer issue observed if from Process A where hid devicebeing added which results in adding a led_cdev addition and later aanother call to access of led_cdev attribute from Process B can resultin NULL pointer issue.Use mutex led_cdev->led_access to protect access to led->cdev and itsattribute inside brightness_show() and max_brightness_show() and alsoupdate the comment for mutex that it should be used to protect the ledclass device fields. Process A Process B kthread+0x114 worker_thread+0x244 process_scheduled_works+0x248 uhid_device_add_worker+0x24 hid_add_device+0x120 device_add+0x268 bus_probe_device+0x94 device_initial_probe+0x14 __device_attach+0xfc bus_for_each_drv+0x10c __device_attach_driver+0x14c driver_probe_device+0x3c __driver_probe_device+0xa0 really_probe+0x190 hid_device_probe+0x130 ps_probe+0x990 ps_led_register+0x94 devm_led_classdev_register_ext+0x58 led_classdev_register_ext+0x1f8 device_create_with_groups+0x48 device_create_groups_vargs+0xc8 device_add+0x244 kobject_uevent+0x14 kobject_uevent_env[jt]+0x224 mutex_unlock[jt]+0xc4 __mutex_unlock_slowpath+0xd4 wake_up_q+0x70 try_to_wake_up[jt]+0x48c preempt_schedule_common+0x28 __schedule+0x628 __switch_to+0x174 el0t_64_sync+0x1a8/0x1ac el0t_64_sync_handler+0x68/0xbc el0_svc+0x38/0x68 do_el0_svc+0x1c/0x28 el0_svc_common+0x80/0xe0 invoke_syscall+0x58/0x114 __arm64_sys_read+0x1c/0x2c ksys_read+0x78/0xe8 vfs_read+0x1e0/0x2c8 kernfs_fop_read_iter+0x68/0x1b4 seq_read_iter+0x158/0x4ec kernfs_seq_show+0x44/0x54 sysfs_kf_seq_show+0xb4/0x130 dev_attr_show+0x38/0x74 brightness_show+0x20/0x4c dualshock4_led_get_brightness+0xc/0x74[ 3313.874295][ T4013] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060[ 3313.874301][ T4013] Mem abort info:[ 3313.874303][ T4013] ESR = 0x0000000096000006[ 3313.874305][ T4013] EC = 0x25: DABT (current EL), IL = 32 bits[ 3313.874307][ T4013] SET = 0, FnV = 0[ 3313.874309][ T4013] EA = 0, S1PTW = 0[ 3313.874311][ T4013] FSC = 0x06: level 2 translation fault[ 3313.874313][ T4013] Data abort info:[ 3313.874314][ T4013] ISV = 0, ISS = 0x00000006, ISS2 = 0x00000000[ 3313.874316][ T4013] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[ 3313.874318][ T4013] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[ 3313.874320][ T4013] user pgtable: 4k pages, 39-bit VAs, pgdp=00000008f2b0a000..[ 3313.874332][ T4013] Dumping ftrace buffer:[ 3313.874334][ T4013] (ftrace buffer empty)....[ dd3313.874639][ T4013] CPU: 6 PID: 4013 Comm: InputReader[ 3313.874648][ T4013] pc : dualshock4_led_get_brightness+0xc/0x74[ 3313.874653][ T4013] lr : led_update_brightness+0x38/0x60[ 3313.874656][ T4013] sp : ffffffc0b910bbd0....[ 3313.874685][ T4013] Call trace:[ 3313.874687][ T4013] dualshock4_led_get_brightness+0xc/0x74[ 3313.874690][ T4013] brightness_show+0x20/0x4c[ 3313.874692][ T4013] dev_attr_show+0x38/0x74[ 3313.874696][ T4013] sysfs_kf_seq_show+0xb4/0x130[ 3313.874700][ T4013] kernfs_seq_show+0x44/0x54[ 3313.874703][ T4013] seq_read_iter+0x158/0x4ec[ 3313.874705][ T4013] kernfs_fop_read_iter+0x68/0x1b4[ 3313.874708][ T4013] vfs_read+0x1e0/0x2c8[ 3313.874711][ T4013] ksys_read+0x78/0xe8[ 3313.874714][ T4013] __arm64_sys_read+0x1c/0x2c[ 3313.874718][ T4013] invoke_syscall+0x58/0x114[ 3313.874721][ T4013] el0_svc_common+0x80/0xe0[ 3313.874724][ T4013] do_el0_svc+0x1c/0x28[ 3313.874727][ T4013] el0_svc+0x38/0x68[ 3313.874730][ T4013] el0t_64_sync_handler+0x68/0xbc[ 3313.874732][ T4013] el0t_64_sync+0x1a8/0x1ac

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56610 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:kcsan: Turn report_filterlist_lock into a raw_spinlockRan Xiaokai reports that with a KCSAN-enabled PREEMPT_RT kernel, we can seesplats like:| BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48| in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1| preempt_count: 10002, expected: 0| RCU nest depth: 0, expected: 0| no locks held by swapper/1/0.| irq event stamp: 156674| hardirqs last enabled at (156673): [] do_idle+0x1f9/0x240| hardirqs last disabled at (156674): [] sysvec_apic_timer_interrupt+0x14/0xc0| softirqs last enabled at (0): [] copy_process+0xfc7/0x4b60| softirqs last disabled at (0): [<0000000000000000>] 0x0| Preemption disabled at:| [] paint_ptr+0x2a/0x90| CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.11.0+ #3| Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-0-ga698c8995f-prebuilt.qemu.org 04/01/2014| Call Trace:| | dump_stack_lvl+0x7e/0xc0| dump_stack+0x1d/0x30| __might_resched+0x1a2/0x270| rt_spin_lock+0x68/0x170| kcsan_skip_report_debugfs+0x43/0xe0| print_report+0xb5/0x590| kcsan_report_known_origin+0x1b1/0x1d0| kcsan_setup_watchpoint+0x348/0x650| __tsan_unaligned_write1+0x16d/0x1d0| hrtimer_interrupt+0x3d6/0x430| __sysvec_apic_timer_interrupt+0xe8/0x3a0| sysvec_apic_timer_interrupt+0x97/0xc0| On a detected data race, KCSAN's reporting logic checks if it shouldfilter the report. That list is protected by the report_filterlist_lock*non-raw* spinlock which may sleep on RT kernels.Since KCSAN may report data races in any context, convert it to araw_spinlock.This requires being careful about when to allocate memory for the filterlist itself which can be done via KCSAN's debugfs interface. Concurrentmodification of the filter list via debugfs should be rare: the chosenstrategy is to optimistically pre-allocate memory before the criticalsection and discard if unused.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56637 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: ipset: Hold module reference while requesting a moduleUser space may unload ip_set.ko while it is itself requesting a set typebackend module, leading to a kernel crash. The race condition may beprovoked by inserting an mdelay() right after the nfnl_unlock() call.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56670 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix the issue that gs_start_io crashed due to accessing null pointerConsidering that in some extreme cases,when u_serial driver is accessed by multiple threads,Thread A is executing the open operation and calling the gs_open,Thread B is executing the disconnect operation and calling thegserial_disconnect function,The port->port_usb pointer will be set to NULL.E.g. Thread A Thread B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) CrashThis causes thread A to access a null pointer (port->port_usb is null)when calling the gs_free_requests function, causing a crash.If port_usb is NULL, the release request will be skipped as itwill be done by gserial_disconnect.So add a null pointer check to gs_start_io before attemptingto access the value of the pointer port->port_usb.Call trace: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invoke_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56700 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: wl128x: Fix atomicity violation in fmc_send_cmd()Atomicity violation occurs when the fmc_send_cmd() function is executedsimultaneously with the modification of the fmdev->resp_skb value.Consider a scenario where, after passing the validity check within thefunction, a non-null fmdev->resp_skb variable is assigned a null value.This results in an invalid fmdev->resp_skb variable passing the validitycheck. As seen in the later part of the function, skb = fmdev->resp_skb;when the invalid fmdev->resp_skb passes the check, a null pointerdereference error may occur at line 478, evt_hdr = (void *)skb->data;To address this issue, it is recommended to include the validity check offmdev->resp_skb within the locked section of the function. Thismodification ensures that the value of fmdev->resp_skb does not changeduring the validation process, thereby maintaining its validity.This possible bug is found by an experimental static analysis tooldeveloped by our team. This tool analyzes the locking APIsto extract function pairs that can be concurrently executed, and thenanalyzes the instructions in the paired functions to identify possibleconcurrency bugs including data races and atomicity violations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56705 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: Add check for rgby_data memory allocation failureIn ia_css_3a_statistics_allocate(), there is no check on the allocationresult of the rgby_data memory. If rgby_data is not successfullyallocated, it may trigger the assert(host_stats->rgby_data) assertion inia_css_s3a_hmem_decode(). Adding a check to fix this potential issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56725 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.cAdd error pointer check after calling otx2_mbox_get_rsp().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56738 Severity: Moderate CVSS3 score: 4.7

Description: GNU GRUB (aka GRUB2) through 2.12 does not use a constant-time algorithm for grub_crypto_memcmp and thus allows side-channel attacks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
grub2 > 0-0 (version in image is 2.06-150400.11.63.1).

CVE-2024-56780 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:quota: flush quota_release_work upon quota writebackOne of the paths quota writeback is called from is:freeze_super() sync_filesystem() ext4_sync_fs() dquot_writeback_dquots()Since we currently don't always flush the quota_release_work queue inthis path, we can end up with the following race: 1. dquot are added to releasing_dquots list during regular operations. 2. FS Freeze starts, however, this does not flush the quota_release_work queue. 3. Freeze completes. 4. Kernel eventually tries to flush the workqueue while FS is frozen which hits a WARN_ON since transaction gets started during frozen state: ext4_journal_check_start+0x28/0x110 [ext4] (unreliable) __ext4_journal_start_sb+0x64/0x1c0 [ext4] ext4_release_dquot+0x90/0x1d0 [ext4] quota_release_workfn+0x43c/0x4d0Which is the following line: WARN_ON(sb->s_writers.frozen == SB_FREEZE_COMPLETE);Which ultimately results in generic/390 failing due to dmesgnoise. This was detected on powerpc machine 15 cores.To avoid this, make sure to flush the workqueue duringdquot_writeback_dquots() so we dont have any pending workitems afterfreeze.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21651 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: don't auto enable misc vectorCurrently, there is a time window between misc irq enabledand service task inited. If an interrupte is reported atthis time, it will cause warning like below:[ 16.324639] Call trace:[ 16.324641] __queue_delayed_work+0xb8/0xe0[ 16.324643] mod_delayed_work_on+0x78/0xd0[ 16.324655] hclge_errhand_task_schedule+0x58/0x90 [hclge][ 16.324662] hclge_misc_irq_handle+0x168/0x240 [hclge][ 16.324666] __handle_irq_event_percpu+0x64/0x1e0[ 16.324667] handle_irq_event+0x80/0x170[ 16.324670] handle_fasteoi_edge_irq+0x110/0x2bc[ 16.324671] __handle_domain_irq+0x84/0xfc[ 16.324673] gic_handle_irq+0x88/0x2c0[ 16.324674] el1_irq+0xb8/0x140[ 16.324677] arch_cpu_idle+0x18/0x40[ 16.324679] default_idle_call+0x5c/0x1bc[ 16.324682] cpuidle_idle_call+0x18c/0x1c4[ 16.324684] do_idle+0x174/0x17c[ 16.324685] cpu_startup_entry+0x30/0x6c[ 16.324687] secondary_start_kernel+0x1a4/0x280[ 16.324688] ---[ end trace 6aa0bff672a964aa ]---So don't auto enable misc vector when request irq..

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21664 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm thin: make get_first_thin use rcu-safe list first functionThe documentation in rculist.h explains the absence of list_empty_rcu()and cautions programmers against relying on a list_empty() ->list_first() sequence in RCU safe code. This is because each of thesefunctions performs its own READ_ONCE() of the list head. This can leadto a situation where the list_empty() sees a valid list entry, but thesubsequent list_first() sees a different view of list head state after amodification.In the case of dm-thin, this author had a production box crash from a GPfault in the process_deferred_bios path. This function saw a valid listhead in get_first_thin() but when it subsequently dereferenced that andturned it into a thin_c, it got the inside of the struct pool, since thelist was now empty and referring to itself. The kernel on which thisoccurred printed both a warning about a refcount_t being saturated, anda UBSAN error for an out-of-bounds cpuid access in the queued spinlock,prior to the fault itself. When the resulting kdump was examined, itwas possible to see another thread patiently waiting in thin_dtr'ssynchronize_rcu.The thin_dtr call managed to pull the thin_c out of the active thinslist (and have it be the last entry in the active_thins list) at justthe wrong moment which lead to this crash.Fortunately, the fix here is straight forward. Switch get_first_thin()function to use list_first_or_null_rcu() which performs just a singleREAD_ONCE() and returns NULL if the list is already empty.This was run against the devicemapper test suite's thin-provisioningsuites for delete and suspend and no regressions were observed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21669 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock/virtio: discard packets if the transport changesIf the socket has been de-assigned or assigned to another transport,we must discard any packets received because they are not expectedand would cause issues when we access vsk->transport.A possible scenario is described by Hyunwoo Kim in the attached link,where after a first connect() interrupted by a signal, and a secondconnect() failed, we can find `vsk->transport` at NULL, leading to aNULL pointer dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21682 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:eth: bnxt: always recalculate features after XDP clearing, fix null-derefRecalculate features when XDP is detached.Before: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: off [requested on]After: # ip li set dev eth0 xdp obj xdp_dummy.bpf.o sec xdp # ip li set dev eth0 xdp off # ethtool -k eth0 | grep gro rx-gro-hw: onThe fact that HW-GRO doesn't get re-enabled automatically is justa minor annoyance. The real issue is that the features will randomlycome back during another reconfiguration which just happens to invokenetdev_update_features(). The driver doesn't handle reconfiguringtwo things at a time very robustly.Starting with commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") we only reconfigure the RSS hash tableif the "effective" number of Rx rings has changed. If HW-GRO isenabled "effective" number of rings is 2x what user sees.So if we are in the bad state, with HW-GRO re-enablement "pending"after XDP off, and we lower the rings by / 2 - the HW-GRO ringsdoing 2x and the ethtool -L doing / 2 may cancel each other out,and the: if (old_rx_rings != bp->hw_resc.resv_rx_rings &&condition in __bnxt_reserve_rings() will be false.The RSS map won't get updated, and we'll crash with: BUG: kernel NULL pointer dereference, address: 0000000000000168 RIP: 0010:__bnxt_hwrm_vnic_set_rss+0x13a/0x1a0 bnxt_hwrm_vnic_rss_cfg_p5+0x47/0x180 __bnxt_setup_vnic_p5+0x58/0x110 bnxt_init_nic+0xb72/0xf50 __bnxt_open_nic+0x40d/0xab0 bnxt_open_nic+0x2b/0x60 ethtool_set_channels+0x18c/0x1d0As we try to access a freed ring.The issue is present since XDP support was added, really, butprior to commit 98ba1d931f61 ("bnxt_en: Fix RSS logic in__bnxt_reserve_rings()") it wasn't causing major issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21684 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: xilinx: Convert gpio_lock to raw spinlockirq_chip functions may be called in raw spinlock context. Therefore, wemust also use a raw spinlock for our own internal locking.This fixes the following lockdep splat:[ 5.349336] =============================[ 5.353349] [ BUG: Invalid wait context ][ 5.357361] 6.13.0-rc5+ #69 Tainted: G W[ 5.363031] -----------------------------[ 5.367045] kworker/u17:1/44 is trying to lock:[ 5.371587] ffffff88018b02c0 (&chip->gpio_lock){....}-{3:3}, at: xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.380079] other info that might help us debug this:[ 5.385138] context-{5:5}[ 5.387762] 5 locks held by kworker/u17:1/44:[ 5.392123] #0: ffffff8800014958 ((wq_completion)events_unbound){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3204)[ 5.402260] #1: ffffffc082fcbdd8 (deferred_probe_work){+.+.}-{0:0}, at: process_one_work (kernel/workqueue.c:3205)[ 5.411528] #2: ffffff880172c900 (&dev->mutex){....}-{4:4}, at: __device_attach (drivers/base/dd.c:1006)[ 5.419929] #3: ffffff88039c8268 (request_class#2){+.+.}-{4:4}, at: __setup_irq (kernel/irq/internals.h:156 kernel/irq/manage.c:1596)[ 5.428331] #4: ffffff88039c80c8 (lock_class#2){....}-{2:2}, at: __setup_irq (kernel/irq/manage.c:1614)[ 5.436472] stack backtrace:[ 5.439359] CPU: 2 UID: 0 PID: 44 Comm: kworker/u17:1 Tainted: G W 6.13.0-rc5+ #69[ 5.448690] Tainted: [W]=WARN[ 5.451656] Hardware name: xlnx,zynqmp (DT)[ 5.455845] Workqueue: events_unbound deferred_probe_work_func[ 5.461699] Call trace:[ 5.464147] show_stack+0x18/0x24 C[ 5.467821] dump_stack_lvl (lib/dump_stack.c:123)[ 5.471501] dump_stack (lib/dump_stack.c:130)[ 5.474824] __lock_acquire (kernel/locking/lockdep.c:4828 kernel/locking/lockdep.c:4898 kernel/locking/lockdep.c:5176)[ 5.478758] lock_acquire (arch/arm64/include/asm/percpu.h:40 kernel/locking/lockdep.c:467 kernel/locking/lockdep.c:5851 kernel/locking/lockdep.c:5814)[ 5.482429] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162)[ 5.486797] xgpio_irq_unmask (drivers/gpio/gpio-xilinx.c:433 (discriminator 8))[ 5.490737] irq_enable (kernel/irq/internals.h:236 kernel/irq/chip.c:170 kernel/irq/chip.c:439 kernel/irq/chip.c:432 kernel/irq/chip.c:345)[ 5.494060] __irq_startup (kernel/irq/internals.h:241 kernel/irq/chip.c:180 kernel/irq/chip.c:250)[ 5.497645] irq_startup (kernel/irq/chip.c:270)[ 5.501143] __setup_irq (kernel/irq/manage.c:1807)[ 5.504728] request_threaded_irq (kernel/irq/manage.c:2208)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21943 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: aggregator: protect driver attr handlers against module unloadBoth new_device_store and delete_device_store touch module globalresources (e.g. gpio_aggregator_lock). To prevent race conditions withmodule unload, a reference needs to be held.Add try_module_get() in these handlers.For new_device_store, this eliminates what appears to be the most dangerousscenario: if an id is allocated from gpio_aggregator_idr butplatform_device_register has not yet been called or completed, a concurrentmodule unload could fail to unregister/delete the device, leaving behind adangling platform device/GPIO forwarder. This can result in various issues.The following simple reproducer demonstrates these problems: #!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait Starting with the following warning, several kinds of warnings will appear and the system may become unstable: ------------[ cut here ]------------ list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120 [...] RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120 [...] Call Trace: ? __list_del_entry_valid_or_report+0xa3/0x120 ? __warn.cold+0x93/0xf2 ? __list_del_entry_valid_or_report+0xa3/0x120 ? report_bug+0xe6/0x170 ? __irq_work_queue_local+0x39/0xe0 ? handle_bug+0x58/0x90 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? __list_del_entry_valid_or_report+0xa3/0x120 gpiod_remove_lookup_table+0x22/0x60 new_device_store+0x315/0x350 [gpio_aggregator] kernfs_fop_write_iter+0x137/0x1f0 vfs_write+0x262/0x430 ksys_write+0x60/0xd0 do_syscall_64+0x6c/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e [...] ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22027 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: streamzap: fix race between device disconnection and urb callbackSyzkaller has reported a general protection fault at functionir_raw_event_store_with_filter(). This crash is caused by a NULL pointerdereference of dev->raw pointer, even though it is checked for NULL inthe same function, which means there is a race condition. It occurs dueto the incorrect order of actions in the streamzap_disconnect() function:rc_unregister_device() is called before usb_kill_urb(). The dev->rawpointer is freed and set to NULL in rc_unregister_device(), and onlyafter that usb_kill_urb() waits for in-progress requests to finish.If rc_unregister_device() is called while streamzap_callback() handler isnot finished, this can lead to accessing freed resources. Thusrc_unregister_device() should be called after usb_kill_urb().Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22030 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()Currently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holdingthe per-CPU acomp_ctx mutex. crypto_free_acomp() then holds scomp_lock(through crypto_exit_scomp_ops_async()).On the other hand, crypto_alloc_acomp_node() holds the scomp_lock (throughcrypto_scomp_init_tfm()), and then allocates memory. If the allocationresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.The above dependencies can cause an ABBA deadlock. For example in thefollowing scenario:(1) Task A running on CPU #1: crypto_alloc_acomp_node() Holds scomp_lock Enters reclaim Reads per_cpu_ptr(pool->acomp_ctx, 1)(2) Task A is descheduled(3) CPU #1 goes offline zswap_cpu_comp_dead(CPU #1) Holds per_cpu_ptr(pool->acomp_ctx, 1)) Calls crypto_free_acomp() Waits for scomp_lock(4) Task A running on CPU #2: Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1 DEADLOCKSince there is no requirement to call crypto_free_acomp() with the per-CPUacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex isunlocked. Also move the acomp_request_free() and kfree() calls forconsistency and to avoid any potential sublte locking dependencies in thefuture.With this, only setting acomp_ctx fields to NULL occurs with the mutexheld. This is similar to how zswap_cpu_comp_prepare() only initializesacomp_ctx fields with the mutex held, after performing all allocationsbefore holding the mutex.Opportunistically, move the NULL check on acomp_ctx so that it takes placebefore the mutex dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22065 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: fix adapter NULL pointer dereference on rebootWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.First via idpf_shutdown() and then again when idpf_remove() calls intosriov_disable(), because the VF devices use the idpf driver, hence thesame remove routine. When that happens, it is possible for the adapterto be NULL from the first call to idpf_remove(), leading to a NULLpointer dereference.echo 1 > /sys/class/net//device/sriov_numvfsrebootBUG: kernel NULL pointer dereference, address: 0000000000000020...RIP: 0010:idpf_remove+0x22/0x1f0 [idpf]...? idpf_remove+0x22/0x1f0 [idpf]? idpf_remove+0x1e4/0x1f0 [idpf]pci_device_remove+0x3f/0xb0device_release_driver_internal+0x19f/0x200pci_stop_bus_device+0x6d/0x90pci_stop_and_remove_bus_device+0x12/0x20pci_iov_remove_virtfn+0xbe/0x120sriov_disable+0x34/0xe0idpf_sriov_configure+0x58/0x140 [idpf]idpf_remove+0x1b9/0x1f0 [idpf]idpf_shutdown+0x12/0x30 [idpf]pci_device_shutdown+0x35/0x60device_shutdown+0x156/0x200...Replace the direct idpf_remove() call in idpf_shutdown() withidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which performthe bulk of the cleanup, such as stopping the init task, freeing IRQs,destroying the vports and freeing the mailbox. This avoids the calls tosriov_disable() in addition to a small netdev cleanup, and destroyingworkqueues, which don't seem to be required on shutdown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37841 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pm: cpupower: bench: Prevent NULL dereference on malloc failureIf malloc returns NULL due to low memory, 'config' pointer can be NULL.Add a check to prevent NULL dereference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37856 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: harden block_group::bg_list against list_del() racesAs far as I can tell, these calls of list_del_init() on bg_list cannotrun concurrently with btrfs_mark_bg_unused() or btrfs_mark_bg_to_reclaim(),as they are in transaction error paths and situations where the blockgroup is readonly.However, if there is any chance at all of racing with mark_bg_unused(),or a different future user of bg_list, better to be safe than sorry.Otherwise we risk the following interleaving (bg_list refcount in parens)T1 (some random op) T2 (btrfs_mark_bg_unused) !list_empty(&bg->bg_list); (1)list_del_init(&bg->bg_list); (1) list_move_tail (1)btrfs_put_block_group (0) btrfs_delete_unused_bgs bg = list_first_entry list_del_init(&bg->bg_list); btrfs_put_block_group(bg); (-1)Ultimately, this results in a broken ref count that hits zero one derefearly and the real final deref underflows the refcount, resulting in a WARNING.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37892 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: inftlcore: Add error check for inftl_read_oob()In INFTL_findwriteunit(), the return value of inftl_read_oob()need to be checked. A proper implementation can befound in INFTL_deleteblock(). The status will be set asSECTOR_IGNORE to break from the while-loop correctlyif the inftl_read_oob() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37928 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm-bufio: don't schedule in atomic contextA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP andtry_verify_in_tasklet are enabled.[ 129.444685][ T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421[ 129.444723][ T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4[ 129.444740][ T934] preempt_count: 201, expected: 0[ 129.444756][ T934] RCU nest depth: 0, expected: 0[ 129.444781][ T934] Preemption disabled at:[ 129.444789][ T934] [] shrink_work+0x21c/0x248[ 129.445167][ T934] kernel BUG at kernel/sched/walt/walt_debug.c:16![ 129.445183][ T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP[ 129.445204][ T934] Skip md ftrace buffer dump for: 0x1609e0[ 129.447348][ T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G W OE 6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8[ 129.447362][ T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)[ 129.447373][ T934] Workqueue: dm_bufio_cache shrink_work[ 129.447394][ T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 129.447406][ T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug][ 129.447435][ T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c[ 129.447451][ T934] sp : ffffffc0843dbc90[ 129.447459][ T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b[ 129.447479][ T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68[ 129.447497][ T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900[ 129.447517][ T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030[ 129.447535][ T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358[ 129.447554][ T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003[ 129.447572][ T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400[ 129.447591][ T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8[ 129.447610][ T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0[ 129.447629][ T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000[ 129.447647][ T934] Call trace:[ 129.447655][ T934] android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6][ 129.447681][ T934] __might_resched+0x190/0x1a8[ 129.447694][ T934] shrink_work+0x180/0x248[ 129.447706][ T934] process_one_work+0x260/0x624[ 129.447718][ T934] worker_thread+0x28c/0x454[ 129.447729][ T934] kthread+0x118/0x158[ 129.447742][ T934] ret_from_fork+0x10/0x20[ 129.447761][ T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)[ 129.447772][ T934] ---[ end trace 0000000000000000 ]---dm_bufio_lock will call spin_lock_bh when try_verify_in_taskletis enabled, and __scan will be called in atomic context.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37942 Severity: Moderate CVSS3 score: 4.7

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37951 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Add job to pending list if the reset was skippedWhen a CL/CSD job times out, we check if the GPU has made any progresssince the last timeout. If so, instead of resetting the hardware, we skipthe reset and let the timer get rearmed. This gives long-running jobs achance to complete.However, when `timedout_job()` is called, the job in question is removedfrom the pending list, which means it won't be automatically freed through`free_job()`. Consequently, when we skip the reset and keep the jobrunning, the job won't be freed when it finally completes.This situation leads to a memory leak, as exposed in [1] and [2].Similarly to commit 704d3d60fec4 ("drm/etnaviv: don't block scheduler whenGPU is still active"), this patch ensures the job is put back on thepending list when extending the timeout.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37983 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:qibfs: fix _another_ leakfailure to allocate inode => leaked dentry...this one had been there since the initial merge; to be fair,if we are that far OOM, the odds of failing at that particularallocation are low...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38102 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:VMCI: fix race between vmci_host_setup_notify and vmci_ctx_unset_notifyDuring our test, it is found that a warning can be trigger in try_grab_folioas follow: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1678 at mm/gup.c:147 try_grab_folio+0x106/0x130 Modules linked in: CPU: 0 UID: 0 PID: 1678 Comm: syz.3.31 Not tainted 6.15.0-rc5 #163 PREEMPT(undef) RIP: 0010:try_grab_folio+0x106/0x130 Call Trace: follow_huge_pmd+0x240/0x8e0 follow_pmd_mask.constprop.0.isra.0+0x40b/0x5c0 follow_pud_mask.constprop.0.isra.0+0x14a/0x170 follow_page_mask+0x1c2/0x1f0 __get_user_pages+0x176/0x950 __gup_longterm_locked+0x15b/0x1060 ? gup_fast+0x120/0x1f0 gup_fast_fallback+0x17e/0x230 get_user_pages_fast+0x5f/0x80 vmci_host_unlocked_ioctl+0x21c/0xf80 RIP: 0033:0x54d2cd ---[ end trace 0000000000000000 ]---Digging into the source, context->notify_page may init by get_user_pages_fastand can be seen in vmci_ctx_unset_notify which will try to put_page. Howeverget_user_pages_fast is not finished here and lead to followingtry_grab_folio warning. The race condition is shown as follow:cpu0 cpu1vmci_host_do_set_notifyvmci_host_setup_notifyget_user_pages_fast(uva, 1, FOLL_WRITE, &context->notify_page);lockless_pages_from_mmgup_pgd_rangegup_huge_pmd // update &context->notify_page vmci_host_do_set_notify vmci_ctx_unset_notify notify_page = context->notify_page; if (notify_page) put_page(notify_page); // page is freed__gup_longterm_locked__get_user_pagesfollow_trans_huge_pmdtry_grab_folio // warn hereTo slove this, use local variable page to make notify_page can be seenafter finish get_user_pages_fast.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38105 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Kill timer properly at removalThe USB-audio MIDI code initializes the timer, but in a rare case, thedriver might be freed without the disconnect call. This leaves thetimer in an active state while the assigned object is released viasnd_usbmidi_free(), which ends up with a kernel warning when the debugconfiguration is enabled, as spotted by fuzzer.For avoiding the problem, put timer_shutdown_sync() atsnd_usbmidi_free(), so that the timer can be killed properly.While we're at it, replace the existing timer_delete_sync() at thedisconnect callback with timer_shutdown_sync(), too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38108 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: red: fix a race in __red_change()Gerrard Tai reported a race condition in RED, whenever SFQ perturb timerfires at the wrong time.The race is as follows:CPU 0 CPU 1[1]: lock root[2]: qdisc_tree_flush_backlog()[3]: unlock root | | [5]: lock root | [6]: rehash | [7]: qdisc_tree_reduce_backlog() |[4]: qdisc_put()This can be abused to underflow a parent's qlen.Calling qdisc_purge_queue() instead of qdisc_tree_flush_backlog()should fix the race, because all packets will be purged from the qdiscbefore releasing the lock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38112 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix TOCTOU issue in sk_is_readable()sk->sk_prot->sock_is_readable is a valid function pointer when sk residesin a sockmap. After the last sk_psock_put() (which usually happens whensocket is removed from sockmap), sk->sk_prot gets restored andsk->sk_prot->sock_is_readable becomes NULL.This makes sk_is_readable() racy, if the value of sk->sk_prot is reloadedafter the initial check. Which in turn may lead to a null pointerdereference.Ensure the function pointer does not turn NULL after the check.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38125 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring ESTIf the ptp_rate recorded earlier in the driver happens to be 0, thisbogus value will propagate up to EST configuration, where it willtrigger a division by 0.Prevent this division by 0 by adding the corresponding check and errorcode.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38126 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: make sure that ptp_rate is not 0 before configuring timestampingThe stmmac platform drivers that do not open-code the clk_ptp_rate valueafter having retrieved the default one from the device-tree can end upwith 0 in clk_ptp_rate (as clk_get_rate can return 0). It willeventually propagate up to PTP initialization when bringing up theinterface, leading to a divide by 0: Division by zero in kernel. CPU: 1 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.30-00001-g48313bd5768a #22 Hardware name: STM32 (Device Tree Support) Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x6c/0x8c dump_stack_lvl from Ldiv0_64+0x8/0x18 Ldiv0_64 from stmmac_init_tstamp_counter+0x190/0x1a4 stmmac_init_tstamp_counter from stmmac_hw_setup+0xc1c/0x111c stmmac_hw_setup from __stmmac_open+0x18c/0x434 __stmmac_open from stmmac_open+0x3c/0xbc stmmac_open from __dev_open+0xf4/0x1ac __dev_open from __dev_change_flags+0x1cc/0x224 __dev_change_flags from dev_change_flags+0x24/0x60 dev_change_flags from ip_auto_config+0x2e8/0x11a0 ip_auto_config from do_one_initcall+0x84/0x33c do_one_initcall from kernel_init_freeable+0x1b8/0x214 kernel_init_freeable from kernel_init+0x24/0x140 kernel_init from ret_from_fork+0x14/0x28 Exception stack(0xe0815fb0 to 0xe0815ff8)Prevent this division by 0 by adding an explicit check and error logabout the actual issue. While at it, remove the same check fromstmmac_ptp_register, which then becomes duplicate

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38203 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix null-ptr-deref in jfs_ioc_trim[ Syzkaller Report ]Oops: general protection fault, probably for non-canonical address0xdffffc0000000087: 0000 [#1KASAN: null-ptr-deref in range [0x0000000000000438-0x000000000000043f]CPU: 2 UID: 0 PID: 10614 Comm: syz-executor.0 Not tainted6.13.0-rc6-gfbfd64d25c7a-dirty #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Sched_ext: serialise (enabled+all), task: runnable_at=-30msRIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:? __die_body+0x61/0xb0? die_addr+0xb1/0xe0? exc_general_protection+0x333/0x510? asm_exc_general_protection+0x26/0x30? jfs_ioc_trim+0x34b/0x8f0jfs_ioctl+0x3c8/0x4f0? __pfx_jfs_ioctl+0x10/0x10? __pfx_jfs_ioctl+0x10/0x10__se_sys_ioctl+0x269/0x350? __pfx___se_sys_ioctl+0x10/0x10? do_syscall_64+0xfb/0x210do_syscall_64+0xee/0x210? syscall_exit_to_user_mode+0x1e0/0x330entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fe51f4903adCode: c3 e8 a7 2b 00 00 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 89 f8 4889 f7 48 89 d6 48 89 ca 4dRSP: 002b:00007fe5202250c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fe51f5cbf80 RCX: 00007fe51f4903adRDX: 0000000020000680 RSI: 00000000c0185879 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 00007fe520225640R13: 000000000000000e R14: 00007fe51f44fca0 R15: 00007fe52021d000Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:jfs_ioc_trim+0x34b/0x8f0Code: e7 e8 59 a4 87 fe 4d 8b 24 24 4d 8d bc 24 38 04 00 00 48 8d 9390 82 fe ff 4c 89 ff 31 f6RSP: 0018:ffffc900055f7cd0 EFLAGS: 00010206RAX: 0000000000000087 RBX: 00005866a9e67ff8 RCX: 000000000000000aRDX: 0000000000000001 RSI: 0000000000000004 RDI: 0000000000000001RBP: dffffc0000000000 R08: ffff88807c180003 R09: 1ffff1100f830000R10: dffffc0000000000 R11: ffffed100f830001 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000438FS: 00007fe520225640(0000) GS:ffff8880b7e80000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005593c91b2c88 CR3: 000000014927c000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Kernel panic - not syncing: Fatal exception[ Analysis ]We believe that we have found a concurrency bug in the `fs/jfs` modulethat results in a null pointer dereference. There is a closely relatedissue which has been fixed:https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6c1b3599b2feb5c7291f5ac3a36e5fa7cedb234... but, unfortunately, the accepted patch appears to still besusceptible to a null pointer dereference under some interleavings.To trigger the bug, we think that `JFS_SBI(ipbmap->i_sb)->bmap` is setto NULL in `dbFreeBits` and then dereferenced in `jfs_ioc_trim`. Thisbug manifests quite rarely under normal circumstances, but istriggereable from a syz-program.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38231 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: Initialize ssc before laundromat_work to prevent NULL dereferenceIn nfs4_state_start_net(), laundromat_work may access nfsd_ssc throughnfs4_laundromat -> nfsd4_ssc_expire_umount. If nfsd_ssc isn't initialized,this can cause NULL pointer dereference.Normally the delayed start of laundromat_work allows sufficient time fornfsd_ssc initialization to complete. However, when the kernel waits toolong for userspace responses (e.g. in nfs4_state_start_net ->nfsd4_end_grace -> nfsd4_record_grace_done -> nfsd4_cld_grace_done ->cld_pipe_upcall -> __cld_pipe_upcall -> wait_for_completion path), thedelayed work may start before nfsd_ssc initialization finishes.Fix this by moving nfsd_ssc initialization before starting laundromat_work.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38234 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:sched/rt: Fix race in push_rt_taskOverview========When a CPU chooses to call push_rt_task and picks a task to push toanother CPU's runqueue then it will call find_lock_lowest_rq methodwhich would take a double lock on both CPUs' runqueues. If one of thelocks aren't readily available, it may lead to dropping the currentrunqueue lock and reacquiring both the locks at once. During this windowit is possible that the task is already migrated and is running on someother CPU. These cases are already handled. However, if the task ismigrated and has already been executed and another CPU is now trying towake 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 thecurrent checks will pass even though the task was migrated out and is nolonger in the pushable tasks list.Crashes=======This bug resulted in quite a few flavors of crashes triggering kernelpanics with various crash signatures such as assert failures, pagefaults, null pointer dereferences, and queue corruption errors allcoming 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---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38244 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when reconnecting channelsFix cifs_signal_cifsd_for_reconnect() to take the correct lock orderand prevent the following deadlock from happening======================================================WARNING: possible circular locking dependency detected6.16.0-rc3-build2+ #1301 Tainted: G S W------------------------------------------------------cifsd/6055 is trying to acquire lock:ffff88810ad56038 (&tcp_ses->srv_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x134/0x200but task is already holding lock:ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200which lock already depends on the new lock.the existing dependency chain (in reverse order) is:-> #2 (&ret_buf->chan_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_setup_session+0x81/0x4b0 cifs_get_smb_ses+0x771/0x900 cifs_mount_get_session+0x7e/0x170 cifs_mount+0x92/0x2d0 cifs_smb3_do_mount+0x161/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #1 (&ret_buf->ses_lock){+.+.}-{3:3}: validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_match_super+0x101/0x320 sget+0xab/0x270 cifs_smb3_do_mount+0x1e0/0x460 smb3_get_tree+0x55/0x90 vfs_get_tree+0x46/0x180 do_new_mount+0x1b0/0x2e0 path_mount+0x6ee/0x740 do_mount+0x98/0xe0 __do_sys_mount+0x148/0x180 do_syscall_64+0xa4/0x260 entry_SYSCALL_64_after_hwframe+0x76/0x7e-> #0 (&tcp_ses->srv_lock){+.+.}-{3:3}: check_noncircular+0x95/0xc0 check_prev_add+0x115/0x2f0 validate_chain+0x1cf/0x270 __lock_acquire+0x60e/0x780 lock_acquire.part.0+0xb4/0x1f0 _raw_spin_lock+0x2f/0x40 cifs_signal_cifsd_for_reconnect+0x134/0x200 __cifs_reconnect+0x8f/0x500 cifs_handle_standard+0x112/0x280 cifs_demultiplex_thread+0x64d/0xbc0 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30other info that might help us debug this:Chain exists of: &tcp_ses->srv_lock --> &ret_buf->ses_lock --> &ret_buf->chan_lock Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&ret_buf->chan_lock); lock(&ret_buf->ses_lock); lock(&ret_buf->chan_lock); lock(&tcp_ses->srv_lock); *** DEADLOCK ***3 locks held by cifsd/6055: #0: ffffffff857de398 (&cifs_tcp_ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x7b/0x200 #1: ffff888119c64060 (&ret_buf->ses_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0x9c/0x200 #2: ffff888119c64330 (&ret_buf->chan_lock){+.+.}-{3:3}, at: cifs_signal_cifsd_for_reconnect+0xcf/0x200

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38245 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:atm: Release atm_dev_mutex after removing procfs in atm_dev_deregister().syzbot reported a warning below during atm_dev_register(). [0]Before creating a new device and procfs/sysfs for it, atm_dev_register()looks up a duplicated device by __atm_dev_lookup(). These operations aredone under atm_dev_mutex.However, when removing a device in atm_dev_deregister(), it releases themutex just after removing the device from the list that __atm_dev_lookup()iterates over.So, there will be a small race window where the device does not exist onthe device list but procfs/sysfs are still not removed, triggering thesplat.Let's hold the mutex until procfs/sysfs are removed inatm_dev_deregister().[0]:proc_dir_entry 'atm/atmtcp:0' already registeredWARNING: CPU: 0 PID: 5919 at fs/proc/generic.c:377 proc_register+0x455/0x5f0 fs/proc/generic.c:377Modules linked in:CPU: 0 UID: 0 PID: 5919 Comm: syz-executor284 Not tainted 6.16.0-rc2-syzkaller-00047-g52da431bf03b #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025RIP: 0010:proc_register+0x455/0x5f0 fs/proc/generic.c:377Code: 48 89 f9 48 c1 e9 03 80 3c 01 00 0f 85 a2 01 00 00 48 8b 44 24 10 48 c7 c7 20 c0 c2 8b 48 8b b0 d8 00 00 00 e8 0c 02 1c ff 90 <0f> 0b 90 90 48 c7 c7 80 f2 82 8e e8 0b de 23 09 48 8b 4c 24 28 48RSP: 0018:ffffc9000466fa30 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817ae248RDX: ffff888026280000 RSI: ffffffff817ae255 RDI: 0000000000000001RBP: ffff8880232bed48 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff888076ed2140R13: dffffc0000000000 R14: ffff888078a61340 R15: ffffed100edda444FS: 00007f38b3b0c6c0(0000) GS:ffff888124753000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f38b3bdf953 CR3: 0000000076d58000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: proc_create_data+0xbe/0x110 fs/proc/generic.c:585 atm_proc_dev_register+0x112/0x1e0 net/atm/proc.c:361 atm_dev_register+0x46d/0x890 net/atm/resources.c:113 atmtcp_create+0x77/0x210 drivers/atm/atmtcp.c:369 atmtcp_attach drivers/atm/atmtcp.c:403 [inline] atmtcp_ioctl+0x2f9/0xd60 drivers/atm/atmtcp.c:464 do_vcc_ioctl+0x12c/0x930 net/atm/ioctl.c:159 sock_do_ioctl+0x115/0x280 net/socket.c:1190 sock_ioctl+0x227/0x6b0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f38b3b74459Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f38b3b0c198 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f38b3bfe318 RCX: 00007f38b3b74459RDX: 0000000000000000 RSI: 0000000000006180 RDI: 0000000000000005RBP: 00007f38b3bfe310 R08: 65732f636f72702f R09: 65732f636f72702fR10: 65732f636f72702f R11: 0000000000000246 R12: 00007f38b3bcb0acR13: 00007f38b3b0c1a0 R14: 0000200000000200 R15: 00007f38b3bcb03b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38250 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix use-after-free in vhci_flush()syzbot reported use-after-free in vhci_flush() without repro. [0]From the splat, a thread close()d a vhci file descriptor whileits device was being used by iotcl() on another thread.Once the last fd refcnt is released, vhci_release() callshci_unregister_dev(), hci_free_dev(), and kfree() for structvhci_data, which is set to hci_dev->dev->driver_data.The problem is that there is no synchronisation after unlinkinghdev from hci_dev_list in hci_unregister_dev(). There might beanother thread still accessing the hdev which was fetched beforethe unlink operation.We can use SRCU for such synchronisation.Let's run hci_dev_reset() under SRCU and wait for its completionin hci_unregister_dev().Another option would be to restore hci_dev->destruct(), which wasremoved in commit 587ae086f6e4 ("Bluetooth: Remove unusedhci-destruct cb"). However, this would not be a good solution, aswe should not run hci_unregister_dev() while there are in-flightioctl() requests, which could lead to another data-race KCSAN splat.Note that other drivers seem to have the same problem, for exmaple,virtbt_remove().[0]:BUG: KASAN: slab-use-after-free in skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline]BUG: KASAN: slab-use-after-free in skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937Read of size 8 at addr ffff88807cb8d858 by task syz.1.219/6718CPU: 1 UID: 0 PID: 6718 Comm: syz.1.219 Not tainted 6.16.0-rc1-syzkaller-00196-g08207f42d3ff #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xd2/0x2b0 mm/kasan/report.c:521 kasan_report+0x118/0x150 mm/kasan/report.c:634 skb_queue_empty_lockless include/linux/skbuff.h:1891 [inline] skb_queue_purge_reason+0x99/0x360 net/core/skbuff.c:3937 skb_queue_purge include/linux/skbuff.h:3368 [inline] vhci_flush+0x44/0x50 drivers/bluetooth/hci_vhci.c:69 hci_dev_do_reset net/bluetooth/hci_core.c:552 [inline] hci_dev_reset+0x420/0x5c0 net/bluetooth/hci_core.c:592 sock_do_ioctl+0xd9/0x300 net/socket.c:1190 sock_ioctl+0x576/0x790 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7fcf5b98e929Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fcf5c7b9038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007fcf5bbb6160 RCX: 00007fcf5b98e929RDX: 0000000000000000 RSI: 00000000400448cb RDI: 0000000000000009RBP: 00007fcf5ba10b39 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007fcf5bbb6160 R15: 00007ffd6353d528 Allocated by task 6535: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3e/0x80 mm/kasan/common.c:68 poison_kmalloc_redzone mm/kasan/common.c:377 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394 kasan_kmalloc include/linux/kasan.h:260 [inline] __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359 kmalloc_noprof include/linux/slab.h:905 [inline] kzalloc_noprof include/linux/slab.h:1039 [inline] vhci_open+0x57/0x360 drivers/bluetooth/hci_vhci.c:635 misc_open+0x2bc/0x330 drivers/char/misc.c:161 chrdev_open+0x4c9/0x5e0 fs/char_dev.c:414 do_dentry_open+0xdf0/0x1970 fs/open.c:964 vfs_open+0x3b/0x340 fs/open.c:1094 do_open fs/namei.c:3887 [inline] path_openat+0x2ee5/0x3830 fs/name---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38293 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix node corruption in ar->arvifs listIn current WLAN recovery code flow, ath11k_core_halt() onlyreinitializes the "arvifs" list head. This will cause thelist node immediately following the list head to become aninvalid list node. Because the prev of that node still pointsto the list head "arvifs", but the next of the list head "arvifs"no longer points to that list node.When a WLAN recovery occurs during the execution of a vifremoval, and it happens before the spin_lock_bh(&ar->data_lock)in ath11k_mac_op_remove_interface(), list_del() will detect thepreviously mentioned situation, thereby triggering a kernel panic.The fix is to remove and reinitialize all vif list nodes from thelist head "arvifs" during WLAN halt. The reinitialization is to makethe list nodes valid, ensuring that the list_del() inath11k_mac_op_remove_interface() can execute normally.Call trace:__list_del_entry_valid_or_report+0xb8/0xd0ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]drv_remove_interface+0x48/0x194 [mac80211]ieee80211_do_stop+0x6e0/0x844 [mac80211]ieee80211_stop+0x44/0x17c [mac80211]__dev_close_many+0xac/0x150__dev_change_flags+0x194/0x234dev_change_flags+0x24/0x6cdevinet_ioctl+0x3a0/0x670inet_ioctl+0x200/0x248sock_do_ioctl+0x60/0x118sock_ioctl+0x274/0x35c__arm64_sys_ioctl+0xac/0xf0invoke_syscall+0x48/0x114...Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38373 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:IB/mlx5: Fix potential deadlock in MR deregistrationThe issue arises when kzalloc() is invoked while holding umem_mutex orany other lock acquired under umem_mutex. This is problematic becausekzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invokemmu_notifier_invalidate_range_start(). This function can lead tomlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,resulting in a deadlock.The problematic flow: CPU0 | CPU1---------------------------------------|------------------------------------------------mlx5_ib_dereg_mr() | -> revoke_mr() | -> mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | -> mutex_lock(&dev->cache.rb_lock) | -> mlx5r_cache_create_ent_locked() | -> kzalloc(GFP_KERNEL) | -> fs_reclaim() | -> mmu_notifier_invalidate_range_start() | -> mlx5_ib_invalidate_range() | -> mutex_lock(&umem_odp->umem_mutex) -> cache_ent_find_and_store() | -> mutex_lock(&dev->cache.rb_lock) |Additionally, when kzalloc() is called from withincache_ent_find_and_store(), we encounter the same deadlock due tore-acquisition of umem_mutex.Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()and before acquiring rb_lock. This ensures that we don't holdumem_mutex while performing memory allocations that could triggerthe reclaim path.This change prevents the deadlock by ensuring proper lock ordering andavoiding holding locks during memory allocation operations that couldtrigger the reclaim path.The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38383 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/vmalloc: fix data race in show_numa_info()The following data-race was found in show_numa_info():==================================================================BUG: KCSAN: data-race in vmalloc_info_show / vmalloc_info_showread to 0xffff88800971fe30 of 4 bytes by task 8289 on cpu 0: show_numa_info mm/vmalloc.c:4936 [inline] vmalloc_info_show+0x5a8/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....write to 0xffff88800971fe30 of 4 bytes by task 8287 on cpu 1: show_numa_info mm/vmalloc.c:4934 [inline] vmalloc_info_show+0x38f/0x7e0 mm/vmalloc.c:5016 seq_read_iter+0x373/0xb40 fs/seq_file.c:230 proc_reg_read_iter+0x11e/0x170 fs/proc/inode.c:299....value changed: 0x0000008f -> 0x00000000==================================================================According to this report,there is a read/write data-race becausem->private is accessible to multiple CPUs. To fix this, instead ofallocating the heap in proc_vmalloc_init() and passing the heap address tom->private, vmalloc_info_show() should allocate the heap.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38387 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Initialize obj_event->obj_sub_list before xa_insertThe obj_event may be loaded immediately after inserted, then if thelist_head is not initialized then we may get a poisonous pointer. Thisfixes the crash below: mlx5_core 0000:03:00.0: MLX5E: StrdRq(1) RqSz(8) StrdSz(2048) RxCqeCmprss(0 enhanced) mlx5_core.sf mlx5_core.sf.4: firmware version: 32.38.3056 mlx5_core 0000:03:00.0 en3f0pf0sf2002: renamed from eth0 mlx5_core.sf mlx5_core.sf.4: Rate limit: 127 rates are supported, range: 0Mbps to 195312Mbps IPv6: ADDRCONF(NETDEV_CHANGE): en3f0pf0sf2002: link becomes ready Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000007760fb000 [0000000000000060] pgd=000000076f6d7003, p4d=000000076f6d7003, pud=0000000777841003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] SMP Modules linked in: ipmb_host(OE) act_mirred(E) cls_flower(E) sch_ingress(E) mptcp_diag(E) udp_diag(E) raw_diag(E) unix_diag(E) tcp_diag(E) inet_diag(E) binfmt_misc(E) bonding(OE) rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) isofs(E) cdrom(E) mst_pciconf(OE) ib_umad(OE) mlx5_ib(OE) ipmb_dev_int(OE) mlx5_core(OE) kpatch_15237886(OEK) mlxdevm(OE) auxiliary(OE) ib_uverbs(OE) ib_core(OE) psample(E) mlxfw(OE) tls(E) sunrpc(E) vfat(E) fat(E) crct10dif_ce(E) ghash_ce(E) sha1_ce(E) sbsa_gwdt(E) virtio_console(E) ext4(E) mbcache(E) jbd2(E) xfs(E) libcrc32c(E) mmc_block(E) virtio_net(E) net_failover(E) failover(E) sha2_ce(E) sha256_arm64(E) nvme(OE) nvme_core(OE) gpio_mlxbf3(OE) mlx_compat(OE) mlxbf_pmc(OE) i2c_mlxbf(OE) sdhci_of_dwcmshc(OE) pinctrl_mlxbf3(OE) mlxbf_pka(OE) gpio_generic(E) i2c_core(E) mmc_core(E) mlxbf_gige(OE) vitesse(E) pwr_mlxbf(OE) mlxbf_tmfifo(OE) micrel(E) mlxbf_bootctl(OE) virtio_ring(E) virtio(E) ipmi_devintf(E) ipmi_msghandler(E) [last unloaded: mst_pci] CPU: 11 PID: 20913 Comm: rte-worker-11 Kdump: loaded Tainted: G OE K 5.10.134-13.1.an8.aarch64 #1 Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.2.2.12968 Oct 26 2023 pstate: a0400089 (NzCv daIf +PAN -UAO -TCO BTYPE=--) pc : dispatch_event_fd+0x68/0x300 [mlx5_ib] lr : devx_event_notifier+0xcc/0x228 [mlx5_ib] sp : ffff80001005bcf0 x29: ffff80001005bcf0 x28: 0000000000000001 x27: ffff244e0740a1d8 x26: ffff244e0740a1d0 x25: ffffda56beff5ae0 x24: ffffda56bf911618 x23: ffff244e0596a480 x22: ffff244e0596a480 x21: ffff244d8312ad90 x20: ffff244e0596a480 x19: fffffffffffffff0 x18: 0000000000000000 x17: 0000000000000000 x16: ffffda56be66d620 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000040 x10: ffffda56bfcafb50 x9 : ffffda5655c25f2c x8 : 0000000000000010 x7 : 0000000000000000 x6 : ffff24545a2e24b8 x5 : 0000000000000003 x4 : ffff80001005bd28 x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff244e0596a480 x0 : ffff244d8312ad90 Call trace: dispatch_event_fd+0x68/0x300 [mlx5_ib] devx_event_notifier+0xcc/0x228 [mlx5_ib] atomic_notifier_call_chain+0x58/0x80 mlx5_eq_async_int+0x148/0x2b0 [mlx5_core] atomic_notifier_call_chain+0x58/0x80 irq_int_handler+0x20/0x30 [mlx5_core] __handle_irq_event_percpu+0x60/0x220 handle_irq_event_percpu+0x3c/0x90 handle_irq_event+0x58/0x158 handle_fasteoi_irq+0xfc/0x188 generic_handle_irq+0x34/0x48 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38393 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:NFSv4/pNFS: Fix a race to wake on NFS_LAYOUT_DRAINWe found a few different systems hung up in writeback waiting on the samepage lock, and one task waiting on the NFS_LAYOUT_DRAIN bit inpnfs_update_layout(), however the pnfs_layout_hdr's plh_outstanding countwas zero.It seems most likely that this is another race between the waiter and wakersimilar to commit ed0172af5d6f ("SUNRPC: Fix a race to wake a sync task").Fix it up by applying the advised barrier.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38428 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Input: ims-pcu - check record size in ims_pcu_flash_firmware()The "len" variable comes from the firmware and we generally dotrust firmware, but it's always better to double check. If the "len"is too large it could result in memory corruption when we do"memcpy(fragment->data, rec->data, len);"

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38436 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: signal scheduled fence when kill jobWhen an entity from application B is killed, drm_sched_entity_kill()removes all jobs belonging to that entity throughdrm_sched_entity_kill_jobs_work(). If application A's job depends on ascheduled fence from application B's job, and that fence is not properlysignaled during the killing process, application A's dependency cannot becleared.This leads to application A hanging indefinitely while waiting for adependency that will never be resolved. Fix this issue by ensuring thatscheduled fences are properly signaled when an entity is killed, allowingdependent applications to continue execution.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38461 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: Fix transport_* TOCTOUTransport assignment may race with module unload. Protect new_transportfrom becoming a stale pointer.This also takes care of an insecure call in vsock_use_local_transport();add a lockdep assert.BUG: unable to handle page fault for address: fffffbfff8056000Oops: Oops: 0000 [#1] SMP KASANRIP: 0010:vsock_assign_transport+0x366/0x600Call Trace: vsock_connect+0x59c/0xc40 __sys_connect+0xe8/0x100 __x64_sys_connect+0x6e/0xc0 do_syscall_64+0x92/0x1c0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38467 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/exynos: exynos7_drm_decon: add vblank check in IRQ handlingIf there's support for another console device (such as a TTY serial),the kernel occasionally panics during boot. The panic message and arelevant snippet of the call stack is as follows: Unable to handle kernel NULL pointer dereference at virtual address 000000000000000 Call trace: drm_crtc_handle_vblank+0x10/0x30 (P) decon_irq_handler+0x88/0xb4 [...]Otherwise, the panics don't happen. This indicates that it's some sortof race condition.Add a check to validate if the drm device can handle vblanks beforecalling drm_crtc_handle_vblank() to avoid this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38473 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix null-ptr-deref in l2cap_sock_resume_cb()syzbot reported null-ptr-deref in l2cap_sock_resume_cb(). [0]l2cap_sock_resume_cb() has a similar problem that was fixed by commit1bff51ea59a9 ("Bluetooth: fix use-after-free error in lock_sock_nested()").Since both l2cap_sock_kill() and l2cap_sock_resume_cb() are executedunder l2cap_sock_resume_cb(), we can avoid the issue simply by checkingif chan->data is NULL.Let's not access to the killed socket in l2cap_sock_resume_cb().[0]:BUG: KASAN: null-ptr-deref in instrument_atomic_write include/linux/instrumented.h:82 [inline]BUG: KASAN: null-ptr-deref in clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline]BUG: KASAN: null-ptr-deref in l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711Write of size 8 at addr 0000000000000570 by task kworker/u9:0/52CPU: 1 UID: 0 PID: 52 Comm: kworker/u9:0 Not tainted 6.16.0-rc4-syzkaller-g7482bb149b9f #0 PREEMPTHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Workqueue: hci0 hci_rx_workCall trace: show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:501 (C) __dump_stack+0x30/0x40 lib/dump_stack.c:94 dump_stack_lvl+0xd8/0x12c lib/dump_stack.c:120 print_report+0x58/0x84 mm/kasan/report.c:524 kasan_report+0xb0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:-1 [inline] kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189 __kasan_check_write+0x20/0x30 mm/kasan/shadow.c:37 instrument_atomic_write include/linux/instrumented.h:82 [inline] clear_bit include/asm-generic/bitops/instrumented-atomic.h:41 [inline] l2cap_sock_resume_cb+0xb4/0x17c net/bluetooth/l2cap_sock.c:1711 l2cap_security_cfm+0x524/0xea0 net/bluetooth/l2cap_core.c:7357 hci_auth_cfm include/net/bluetooth/hci_core.h:2092 [inline] hci_auth_complete_evt+0x2e8/0xa4c net/bluetooth/hci_event.c:3514 hci_event_func net/bluetooth/hci_event.c:7511 [inline] hci_event_packet+0x650/0xe9c net/bluetooth/hci_event.c:7565 hci_rx_work+0x320/0xb18 net/bluetooth/hci_core.c:4070 process_one_work+0x7e8/0x155c kernel/workqueue.c:3238 process_scheduled_works kernel/workqueue.c:3321 [inline] worker_thread+0x958/0xed8 kernel/workqueue.c:3402 kthread+0x5fc/0x75c kernel/kthread.c:464 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38513 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: zd1211rw: Fix potential NULL pointer dereference in zd_mac_tx_to_dev()There is a potential NULL pointer dereference in zd_mac_tx_to_dev(). Forexample, the following is possible: T0 T1zd_mac_tx_to_dev() /* len == skb_queue_len(q) */ while (len > ZD_MAC_MAX_ACK_WAITERS) { filter_ack() spin_lock_irqsave(&q->lock, flags); /* position == skb_queue_len(q) */ for (i=1; itype == NL80211_IFTYPE_AP) skb = __skb_dequeue(q); spin_unlock_irqrestore(&q->lock, flags); skb_dequeue() -> NULLSince there is a small gap between checking skb queue length and skb beingunconditionally dequeued in zd_mac_tx_to_dev(), skb_dequeue() can return NULL.Then the pointer is passed to zd_mac_tx_status() where it is dereferenced.In order to avoid potential NULL pointer dereference due to situations likeabove, check if skb is not NULL before passing it to zd_mac_tx_status().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38515 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Increment job count before swapping tail spsc queueA small race exists between spsc_queue_push and the run-job worker, inwhich spsc_queue_push may return not-first while the run-job worker hasalready idled due to the job count being zero. If this race occurs, jobscheduling stops, leading to hangs while waiting on the job's DMAfences.Seal this race by incrementing the job count before appending to theSPSC queue.This race was observed on a drm-tip 6.16-rc1 build with the Xe driver inan SVM test case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38520 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Don't call mmput from MMU notifier callbackIf the process is exiting, the mmput inside mmu notifier callback fromcompactd or fork or numa balancing could release the last referenceof mm struct to call exit_mmap and free_pgtable, this triggers deadlockwith below backtrace.The deadlock will leak kfd process as mmu notifier release is not calledand cause VRAM leaking.The fix is to take mm reference mmget_non_zero when adding prange to thedeferred list to pair with mmput in deferred list work.If prange split and add into pchild list, the pchild work_item.mm is notused, so remove the mm parameter from svm_range_unmap_split andsvm_range_add_child.The backtrace of hung task: INFO: task python:348105 blocked for more than 64512 seconds. Call Trace: __schedule+0x1c3/0x550 schedule+0x46/0xb0 rwsem_down_write_slowpath+0x24b/0x4c0 unlink_anon_vmas+0xb1/0x1c0 free_pgtables+0xa9/0x130 exit_mmap+0xbc/0x1a0 mmput+0x5a/0x140 svm_range_cpu_invalidate_pagetables+0x2b/0x40 [amdgpu] mn_itree_invalidate+0x72/0xc0 __mmu_notifier_invalidate_range_start+0x48/0x60 try_to_unmap_one+0x10fa/0x1400 rmap_walk_anon+0x196/0x460 try_to_unmap+0xbb/0x210 migrate_page_unmap+0x54d/0x7e0 migrate_pages_batch+0x1c3/0xae0 migrate_pages_sync+0x98/0x240 migrate_pages+0x25c/0x520 compact_zone+0x29d/0x590 compact_zone_order+0xb6/0xf0 try_to_compact_pages+0xbe/0x220 __alloc_pages_direct_compact+0x96/0x1a0 __alloc_pages_slowpath+0x410/0x930 __alloc_pages_nodemask+0x3a9/0x3e0 do_huge_pmd_anonymous_page+0xd7/0x3e0 __handle_mm_fault+0x5e3/0x5f0 handle_mm_fault+0xf7/0x2e0 hmm_vma_fault.isra.0+0x4d/0xa0 walk_pmd_range.isra.0+0xa8/0x310 walk_pud_range+0x167/0x240 walk_pgd_range+0x55/0x100 __walk_page_range+0x87/0x90 walk_page_range+0xf6/0x160 hmm_range_fault+0x4f/0x90 amdgpu_hmm_range_get_pages+0x123/0x230 [amdgpu] amdgpu_ttm_tt_get_user_pages+0xb1/0x150 [amdgpu] init_user_pages+0xb1/0x2a0 [amdgpu] amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0x543/0x7d0 [amdgpu] kfd_ioctl_alloc_memory_of_gpu+0x24c/0x4e0 [amdgpu] kfd_ioctl+0x29d/0x500 [amdgpu](cherry picked from commit a29e067bd38946f752b0ef855f3dfff87e77bec7)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38538 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: nbpfaxi: Fix memory corruption in probe()The nbpf->chan[] array is allocated earlier in the nbpf_probe() functionand it has "num_channels" elements. These three loops iterate oneelement farther than they should and corrupt memory.The changes to the second loop are more involved. In this case, we'recopying data from the irqbuf[] array into the nbpf->chan[] array. Ifthe data in irqbuf[i] is the error IRQ then we skip it, so the iteratorsare not in sync. I added a check to ensure that we don't go beyond theend of the irqbuf[] array. I'm pretty sure this can't happen, but itseemed harmless to add a check.On the other hand, after the loop has ended there is a check to ensurethat the "chan" iterator is where we expect it to be. In the originalcode we went one element beyond the end of the array so the iteratorwasn't in the correct place and it would always return -EINVAL. However,now it will always be in the correct place. I deleted the check sincewe know the result.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38544 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:rxrpc: Fix bug due to prealloc collisionWhen userspace is using AF_RXRPC to provide a server, it has to preallocateincoming calls and assign to them call IDs that will be used to threadrelated recvmsg() and sendmsg() together. The preallocated call IDs willautomatically be attached to calls as they come in until the pool is empty.To the kernel, the call IDs are just arbitrary numbers, but userspace canuse the call ID to hold a pointer to prepared structs. In any case, theuser isn't permitted to create two calls with the same call ID (call IDsbecome available again when the call ends) and EBADSLT should result fromsendmsg() if an attempt is made to preallocate a call with an in-use callID.However, the cleanup in the error handling will trigger both assertions inrxrpc_cleanup_call() because the call isn't marked complete and isn'tmarked as having been released.Fix this by setting the call state in rxrpc_service_prealloc_one() and thenmarking it as being released before calling the cleanup function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38576 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: Make EEH driver device hotplug safeMultiple race conditions existed between the PCIe hotplug driver and theEEH driver, leading to a variety of kernel oopses of the same generalnature:A second class of oops is also seen when the underlying bus disappearsduring device recovery.Refactor the EEH module to be PCI rescan and remove safe. Also cleanup a few minor formatting / readability issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38595 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:xen: fix UAF in dmabuf_exp_from_pages()[dma_buf_fd() fixes; no preferences regarding the tree it goes through -up to xen folks]As soon as we'd inserted a file reference into descriptor table, anotherthread could close it. That's fine for the case when all we are doing isreturning that descriptor to userland (it's a race, but it's a userlandrace and there's nothing the kernel can do about it). However, if wefollow fd_install() with any kind of access to objects that would bedestroyed on close (be it the struct file itself or anything destroyedby its ->release()), we have a UAF.dma_buf_fd() is a combination of reserving a descriptor and fd_install().gntdev dmabuf_exp_from_pages() calls it and then proceeds to access theobjects destroyed on close - starting with gntdev_dmabuf itself.Fix that by doing reserving descriptor before anything else and dofd_install() only when everything had been set up.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38637 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net_sched: skbprio: Remove overly strict queue assertionsIn the current implementation, skbprio enqueue/dequeue contains an assertionthat fails under certain conditions when SKBPRIO is used as a child qdisc underTBF with specific parameters. The failure occurs because TBF sometimes peeks atpackets in the child qdisc without actually dequeuing them when tokens areunavailable.This peek operation creates a discrepancy between the parent and child qdiscqueue length counters. When TBF later receives a high-priority packet,SKBPRIO's queue length may show a different value than what's reflected in itsinternal priority queue tracking, triggering the assertion.The fix removes this overly strict assertions in SKBPRIO, they are notnecessary at all.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38650 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: remove mutex_lock check in hfsplus_free_extentsSyzbot reported an issue in hfsplus filesystem:------------[ cut here ]------------WARNING: CPU: 0 PID: 4400 at fs/hfsplus/extents.c:346 hfsplus_free_extents+0x700/0xad0Call Trace:hfsplus_file_truncate+0x768/0xbb0 fs/hfsplus/extents.c:606hfsplus_write_begin+0xc2/0xd0 fs/hfsplus/inode.c:56cont_expand_zero fs/buffer.c:2383 [inline]cont_write_begin+0x2cf/0x860 fs/buffer.c:2446hfsplus_write_begin+0x86/0xd0 fs/hfsplus/inode.c:52generic_cont_expand_simple+0x151/0x250 fs/buffer.c:2347hfsplus_setattr+0x168/0x280 fs/hfsplus/inode.c:263notify_change+0xe38/0x10f0 fs/attr.c:420do_truncate+0x1fb/0x2e0 fs/open.c:65do_sys_ftruncate+0x2eb/0x380 fs/open.c:193do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdTo avoid deadlock, Commit 31651c607151 ("hfsplus: avoid deadlockon file truncation") unlock extree before hfsplus_free_extents(),and add check wheather extree is locked in hfsplus_free_extents().However, when operations such as hfsplus_file_release,hfsplus_setattr, hfsplus_unlink, and hfsplus_get_block are executedconcurrently in different files, it is very likely to trigger theWARN_ON, which will lead syzbot and xfstest to consider it as anabnormality.The comment above this warning also describes one of the easytriggering situations, which can easily trigger and causexfstest&syzbot to report errors.[task A] [task B]->hfsplus_file_release ->hfsplus_file_truncate ->hfs_find_init ->mutex_lock ->mutex_unlock ->hfsplus_write_begin ->hfsplus_get_block ->hfsplus_file_extend ->hfsplus_ext_read_extent ->hfs_find_init ->mutex_lock ->hfsplus_free_extents WARN_ON(mutex_is_locked) !!!Several threads could try to lock the shared extents tree.And warning can be triggered in one thread when another threadhas locked the tree. This is the wrong behavior of the code andwe need to remove the warning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38695 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Check for hdwq null ptr when cleaning up lpfc_vport structureIf a call to lpfc_sli4_read_rev() from lpfc_sli4_hba_setup() fails, theresultant cleanup routine lpfc_sli4_vport_delete_fcp_xri_aborted() mayoccur before sli4_hba.hdwqs are allocated. This may result in a nullpointer dereference when attempting to take the abts_io_buf_list_lock forthe first hardware queue. Fix by adding a null ptr check onphba->sli4_hba.hdwq and early return because this situation means theremust have been an error during port initialization.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38701 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: do not BUG when INLINE_DATA_FL lacks system.data xattrA syzbot fuzzed image triggered a BUG_ON in ext4_update_inline_data()when an inode had the INLINE_DATA_FL flag set but was missing thesystem.data extended attribute.Since this can happen due to a maiciouly fuzzed file system, weshouldn't BUG, but rather, report it as a corrupted file system.Add similar replacements of BUG_ON with EXT4_ERROR_INODE() iiext4_create_inline_data() and ext4_inline_data_truncate().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39736 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid deadlock by moving pr_warn() outside kmemleak_lockWhen netpoll is enabled, calling pr_warn_once() while holdingkmemleak_lock in mem_pool_alloc() can cause a deadlock due to lockinversion with the netconsole subsystem. This occurs becausepr_warn_once() may trigger netpoll, which eventually leads to__alloc_skb() and back into kmemleak code, attempting to reacquirekmemleak_lock.This is the path for the deadlock.mem_pool_alloc() -> raw_spin_lock_irqsave(&kmemleak_lock, flags); -> pr_warn_once() -> netconsole subsystem -> netpoll -> __alloc_skb -> __create_object -> raw_spin_lock_irqsave(&kmemleak_lock, flags);Fix this by setting a flag and issuing the pr_warn_once() afterkmemleak_lock is released.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39889 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: Check encryption key size on incoming connectionThis is required for passing GAP/SEC/SEM/BI-04-C PTS test case: Security Mode 4 Level 4, Responder - Invalid Encryption Key Size - 128 bitThis tests the security key with size from 1 to 15 bytes while theSecurity Mode 4 Level 4 requests 16 bytes key size.Currently PTS fails with the following logs:- expected:Connection Response: Code: [3 (0x03)] Code Identifier: (lt)WildCard: Exists(gt) Length: [8 (0x0008)] Destination CID: (lt)WildCard: Exists(gt) Source CID: [64 (0x0040)] Result: [3 (0x0003)] Connection refused - Security block Status: (lt)WildCard: Exists(gt),but received:Connection Response: Code: [3 (0x03)] Code Identifier: [1 (0x01)] Length: [8 (0x0008)] Destination CID: [64 (0x0040)] Source CID: [64 (0x0040)] Result: [0 (0x0000)] Connection Successful Status: [0 (0x0000)] No further information availableAnd HCI logs:< HCI Command: Read Encrypti.. (0x05|0x0008) plen 2 Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.)> HCI Event: Command Complete (0x0e) plen 7 Read Encryption Key Size (0x05|0x0008) ncmd 1 Status: Success (0x00) Handle: 14 Address: 00:1B:DC:F2:24:10 (Vencer Co., Ltd.) Key size: 7> ACL Data RX: Handle 14 flags 0x02 dlen 12 L2CAP: Connection Request (0x02) ident 1 len 4 PSM: 4097 (0x1001) Source CID: 64< ACL Data TX: Handle 14 flags 0x00 dlen 16 L2CAP: Connection Response (0x03) ident 1 len 8 Destination CID: 64 Source CID: 64 Result: Connection successful (0x0000) Status: No further information available (0x0000)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39891 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Initialize the chan_stats array to zeroThe adapter->chan_stats[] array is initialized inmwifiex_init_channel_scan_gap() with vmalloc(), which doesn't zero outmemory. The array is filled in mwifiex_update_chan_statistics()and then the user can query the data in mwifiex_cfg80211_dump_survey().There are two potential issues here. What if the user callsmwifiex_cfg80211_dump_survey() before the data has been filled in.Also the mwifiex_update_chan_statistics() function doesn't necessarilyinitialize the whole array. Since the array was not initialized atthe start that could result in an information leak.Also this array is pretty small. It's a maximum of 900 bytes so it'smore appropriate to use kcalloc() instead vmalloc().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39953 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cgroup: split cgroup_destroy_wq into 3 workqueuesA hung task can occur during [1] LTP cgroup testing when repeatedlymounting/unmounting perf_event and net_prio controllers withsystemd.unified_cgroup_hierarchy=1. The hang manifests incgroup_lock_and_drain_offline() during root destruction.Related case:cgroup_fj_function_perf_event cgroup_fj_function.sh perf_eventcgroup_fj_function_net_prio cgroup_fj_function.sh net_prioCall Trace: cgroup_lock_and_drain_offline+0x14c/0x1e8 cgroup_destroy_root+0x3c/0x2c0 css_free_rwork_fn+0x248/0x338 process_one_work+0x16c/0x3b8 worker_thread+0x22c/0x3b0 kthread+0xec/0x100 ret_from_fork+0x10/0x20Root Cause:CPU0 CPU1mount perf_event umount net_priocgroup1_get_tree cgroup_kill_sbrebind_subsystems // root destruction enqueues // cgroup_destroy_wq// kill all perf_event css // one perf_event css A is dying // css A offline enqueues cgroup_destroy_wq // root destruction will be executed first css_free_rwork_fn cgroup_destroy_root cgroup_lock_and_drain_offline // some perf descendants are dying // cgroup_destroy_wq max_active = 1 // waiting for css A to dieProblem scenario:1. CPU0 mounts perf_event (rebind_subsystems)2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work3. A dying perf_event CSS gets queued for offline after root destruction4. Root destruction waits for offline completion, but offline work is blocked behind root destruction in cgroup_destroy_wq (max_active=1)Solution:Split cgroup_destroy_wq into three dedicated workqueues:cgroup_offline_wq - Handles CSS offline operationscgroup_release_wq - Manages resource releasecgroup_free_wq - Performs final memory deallocationThis separation eliminates blocking in the CSS free path while waiting foroffline operations to complete.[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40006 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix folio is still mapped when deletedMigration may be raced with fallocating hole. remove_inode_single_foliowill unmap the folio if the folio is still mapped. However, it's calledwithout folio lock. If the folio is migrated and the mapped pte has beenconverted to migration entry, folio_mapped() returns false, and won'tunmap it. Due to extra refcount held by remove_inode_single_folio,migration fails, restores migration entry to normal pte, and the folio ismapped again. As a result, we triggered BUG in filemap_unaccount_folio.The log is as follows: BUG: Bad page cache in process hugetlb pfn:156c00 page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00 head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0 aops:hugetlbfs_aops ino:dcc dentry name(?):"my_hugepage_file" flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: f4(hugetlb) page dumped because: still mapped when deleted CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack_lvl+0x4f/0x70 filemap_unaccount_folio+0xc4/0x1c0 __filemap_remove_folio+0x38/0x1c0 filemap_remove_folio+0x41/0xd0 remove_inode_hugepages+0x142/0x250 hugetlbfs_fallocate+0x471/0x5a0 vfs_fallocate+0x149/0x380Hold folio lock before checking if the folio is mapped to avold race withmigration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40111 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix Use-after-free in validationNodes stored in the validation duplicates hashtable come from an arenaallocator that is cleared at the end of vmw_execbuf_process. All nodesare expected to be cleared in vmw_validation_drop_ht but this node escapedbecause its resource was destroyed prematurely.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40134 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:dm: fix NULL pointer dereference in __dm_suspend()There is a race condition between dm device suspend and table load thatcan lead to null pointer dereference. The issue occurs when suspend isinvoked before table load completes:BUG: kernel NULL pointer dereference, address: 0000000000000054Oops: 0000 [#1] PREEMPT SMP PTICPU: 6 PID: 6798 Comm: dmsetup Not tainted 6.6.0-g7e52f5f0ca9b #62Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014RIP: 0010:blk_mq_wait_quiesce_done+0x0/0x50Call Trace: blk_mq_quiesce_queue+0x2c/0x50 dm_stop_queue+0xd/0x20 __dm_suspend+0x130/0x330 dm_suspend+0x11a/0x180 dev_suspend+0x27e/0x560 ctl_ioctl+0x4cf/0x850 dm_ctl_ioctl+0xd/0x20 vfs_ioctl+0x1d/0x50 __se_sys_ioctl+0x9b/0xc0 __x64_sys_ioctl+0x19/0x30 x64_sys_call+0x2c4a/0x4620 do_syscall_64+0x9e/0x1b0The issue can be triggered as below:T1 T2dm_suspend table_load__dm_suspend dm_setup_md_queue dm_mq_init_request_queue blk_mq_init_allocated_queue => q->mq_ops = set->ops; (1)dm_stop_queue / dm_wait_for_completion=> q->tag_set NULL pointer! (2) => q->tag_set = set; (3)Fix this by checking if a valid table (map) exists before performingrequest-based suspend and waiting for target I/O. When map is NULL,skip these table-dependent suspend steps.Even when map is NULL, no I/O can reach any target because there isno table loaded; I/O submitted in this state will fail early in theDM layer. Skipping the table-dependent suspend logic in this caseis safe and avoids NULL pointer dereferences.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40146 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix potential deadlock while nr_requests grownAllocate and free sched_tags while queue is freezed can deadlock[1],this is a long term problem, hence allocate memory before freezingqueue and free memory after queue is unfreezed.[1] https://lore.kernel.org/all/0659ea8d-a463-47c8-9180-43c719e106eb@linux.ibm.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40164 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usbnet: Fix using smp_processor_id() in preemptible code warningsSyzbot reported the following warning:BUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879caller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49 usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 __dev_set_mtu net/core/dev.c:9443 [inline] netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496 netif_set_mtu+0xb0/0x160 net/core/dev.c:9520 dev_set_mtu+0xae/0x170 net/core/dev_api.c:247 dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572 dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821 sock_do_ioctl+0x19d/0x280 net/socket.c:1204 sock_ioctl+0x42f/0x6a0 net/socket.c:1311 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:906 [inline] __se_sys_ioctl fs/ioctl.c:892 [inline] __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fFor historical and portability reasons, the netif_rx() is usuallyrun in the softirq or interrupt context, this commit therefore addlocal_bh_disable/enable() protection in the usbnet_resume_rx().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40173 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:net/ip6_tunnel: Prevent perpetual tunnel growthSimilarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too.While ipv4 tunnel headroom adjustment growth was limited incommit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"),ipv6 tunnel yet increases the headroom without any ceiling.Reflect ipv4 tunnel headroom adjustment limit on ipv6 version.Credits to Francesco Ruggeri, who was originally debugging this issueand wrote local Arista-specific patch and a reproducer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40194 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: intel_pstate: Fix object lifecycle issue in update_qos_request()The cpufreq_cpu_put() call in update_qos_request() takes place too earlybecause the latter subsequently calls freq_qos_update_request() thatindirectly accesses the policy object in question through the QoS requestobject passed to it.Fortunately, update_qos_request() is called under intel_pstate_driver_lock,so this issue does not matter for changing the intel_pstate operationmode, but it theoretically can cause a crash to occur on CPU device hotremoval (which currently can only happen in virt, but it is formallysupported nevertheless).Address this issue by modifying update_qos_request() to drop thereference to the policy later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40268 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: client: fix memory leak in smb3_fs_context_parse_paramThe user calls fsconfig twice, but when the program exits, free() onlyfrees ctx->source for the second fsconfig, not the first.Regarding fc->source, there is no code in the fs context related to itsmemory reclamation.To fix this memory leak, release the source memory corresponding to ctxor fc before each parsing.syzbot reported:BUG: memory leakunreferenced object 0xffff888128afa360 (size 96): backtrace (crc 79c9c7ba): kstrdup+0x3c/0x80 mm/util.c:84 smb3_fs_context_parse_param+0x229b/0x36c0 fs/smb/client/fs_context.c:1444BUG: memory leakunreferenced object 0xffff888112c7d900 (size 96): backtrace (crc 79c9c7ba): smb3_fs_context_fullpath+0x70/0x1b0 fs/smb/client/fs_context.c:629 smb3_fs_context_parse_param+0x2266/0x36c0 fs/smb/client/fs_context.c:1438

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68321 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: always add GFP_NOWARN for ATOMIC allocationsDriver authors often forget to add GFP_NOWARN for page allocationfrom the datapath. This is annoying to users as OOMs are a factof life, and we pretty much expect network Rx to hit page allocationfailures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocationsby default.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68327 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:usb: renesas_usbhs: Fix synchronous external abort on unbindA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind isexecuted after the configuration sequence described above:modprobe usb_f_ecmmodprobe libcompositemodprobe configfscd /sys/kernel/config/usb_gadgetmkdir -p g1cd g1echo "0x1d6b" > idVendorecho "0x0104" > idProductmkdir -p strings/0x409echo "0123456789" > strings/0x409/serialnumberecho "Renesas." > strings/0x409/manufacturerecho "Ethernet Gadget" > strings/0x409/productmkdir -p functions/ecm.usb0mkdir -p configs/c.1mkdir -p configs/c.1/strings/0x409echo "ECM" > configs/c.1/strings/0x409/configurationif [ ! -L configs/c.1/ecm.usb0 ]; then ln -s functions/ecm.usb0 configs/c.1fiecho 11e20000.usb > UDCecho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbindThe displayed trace is as follows: Internal error: synchronous external abort: 0000000096000010 [#1] SMP CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT Tainted: [M]=MACHINE_CHECK Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs] sp : ffff8000838b3920 x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810 x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000 x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020 x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344 x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000 x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418 x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000 x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80 Call trace: usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P) usbhsg_pullup+0x4c/0x7c [renesas_usbhs] usb_gadget_disconnect_locked+0x48/0xd4 gadget_unbind_driver+0x44/0x114 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_release_driver+0x18/0x24 bus_remove_device+0xcc/0x10c device_del+0x14c/0x404 usb_del_gadget+0x88/0xc0 usb_del_gadget_udc+0x18/0x30 usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs] usbhs_mod_remove+0x20/0x30 [renesas_usbhs] usbhs_remove+0x98/0xdc [renesas_usbhs] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 device_driver_detach+0x18/0x24 unbind_store+0xb4/0xb8 drv_attr_store+0x24/0x38 sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x128/0x1b8 vfs_write+0x2ac/0x350 ksys_write+0x68/0xfc __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021) ---[ end trace 0000000000000000 ]--- note: sh[188] exited with irqs disabled note: sh[188] exited with preempt_count 1The issue occurs because usbhs_sys_function_pullup(), which accesses the IPregisters, is executed after the USBHS clocks have been disabled. Theproblem is reproducible on the Renesas RZ/G3S SoC starting with theaddition of module stop in the clock enable/disable APIs. With module stopfunctionality enabled, a bus error is expected if a master accesses amodule whose clock has been stopped and module stop activated.Disable the IP clocks at the end of remove.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68745 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Clear cmds after chip resetCommit aefed3e5548f ("scsi: qla2xxx: target: Fix offline port handlingand host reset handling") caused two problems:1. Commands sent to FW, after chip reset got stuck and never freed as FW is not going to respond to them anymore.2. BUG_ON(cmd->sg_mapped) in qlt_free_cmd(). Commit 26f9ce53817a ("scsi: qla2xxx: Fix missed DMA unmap for aborted commands") attempted to fix this, but introduced another bug under different circumstances when two different CPUs were racing to call qlt_unmap_sg() at the same time: BUG_ON(!valid_dma_direction(dir)) in dma_unmap_sg_attrs().So revert "scsi: qla2xxx: Fix missed DMA unmap for aborted commands" andpartially revert "scsi: qla2xxx: target: Fix offline port handling andhost reset handling" at __qla2x00_abort_all_cmds.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68746 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:spi: tegra210-quad: Fix timeout handlingWhen the CPU that the QSPI interrupt handler runs on (typically CPU 0)is excessively busy, it can lead to rare cases of the IRQ thread notrunning before the transfer timeout is reached.While handling the timeouts, any pending transfers are cleaned up andthe message that they correspond to is marked as failed, which leavesthe curr_xfer field pointing at stale memory.To avoid this, clear curr_xfer to NULL upon timeout and check for thiscondition when the IRQ thread is finally run.While at it, also make sure to clear interrupts on failure so that newinterrupts can be run.A better, more involved, fix would move the interrupt clearing into ahard IRQ handler. Ideally we would also want to signal that the IRQthread no longer needs to be run after the timeout is hit to avoid theextra check for a valid transfer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68772 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid updating compression context during writebackBai, Shuangpeng reported a bug as below:Oops: divide error: 0000 [#1] SMP KASAN PTICPU: 0 UID: 0 PID: 11441 Comm: syz.0.46 Not tainted 6.17.0 #1 PREEMPT(full)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:f2fs_all_cluster_page_ready+0x106/0x550 fs/f2fs/compress.c:857Call Trace: f2fs_write_cache_pages fs/f2fs/data.c:3078 [inline] __f2fs_write_data_pages fs/f2fs/data.c:3290 [inline] f2fs_write_data_pages+0x1c19/0x3600 fs/f2fs/data.c:3317 do_writepages+0x38e/0x640 mm/page-writeback.c:2634 filemap_fdatawrite_wbc mm/filemap.c:386 [inline] __filemap_fdatawrite_range mm/filemap.c:419 [inline] file_write_and_wait_range+0x2ba/0x3e0 mm/filemap.c:794 f2fs_do_sync_file+0x6e6/0x1b00 fs/f2fs/file.c:294 generic_write_sync include/linux/fs.h:3043 [inline] f2fs_file_write_iter+0x76e/0x2700 fs/f2fs/file.c:5259 new_sync_write fs/read_write.c:593 [inline] vfs_write+0x7e9/0xe00 fs/read_write.c:686 ksys_write+0x19d/0x2d0 fs/read_write.c:738 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xf7/0x470 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe bug was triggered w/ below race condition:fsync setattr ioctl- f2fs_do_sync_file - file_write_and_wait_range - f2fs_write_cache_pages : inode is non-compressed : cc.cluster_size = F2FS_I(inode)->i_cluster_size = 0 - tag_pages_for_writeback - f2fs_setattr - truncate_setsize - f2fs_truncate - f2fs_fileattr_set - f2fs_setflags_common - set_compress_context : F2FS_I(inode)->i_cluster_size = 4 : set_inode_flag(inode, FI_COMPRESSED_FILE) - f2fs_compressed_file : return true - f2fs_all_cluster_page_ready : "pgidx % cc->cluster_size" trigger dividing 0 issueLet's change as below to fix this issue:- introduce a new atomic type variable .writeback in structure f2fs_inode_infoto track the number of threads which calling f2fs_write_cache_pages().- use .i_sem lock to protect .writeback update.- check .writeback before update compression context in f2fs_setflags_common()to avoid race w/ ->writepages.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68774 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix missing hfs_bnode_get() in __hfs_bnode_createWhen sync() and link() are called concurrently, both threads mayenter hfs_bnode_find() without finding the node in the hash tableand proceed to create it.Thread A: hfsplus_write_inode() -> hfsplus_write_system_inode() -> hfs_btree_write() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)Thread B: hfsplus_create_cat() -> hfs_brec_insert() -> hfs_bnode_split() -> hfs_bmap_alloc() -> hfs_bnode_find(tree, 0) -> __hfs_bnode_create(tree, 0)In this case, thread A creates the bnode, sets refcnt=1, and hashes it.Thread B also tries to create the same bnode, notices it has alreadybeen inserted, drops its own instance, and uses the hashed one withoutgetting the node.``` node2 = hfs_bnode_findhash(tree, cnid); if (!node2) { <- Thread A hash = hfs_bnode_hash(cnid); node->next_hash = tree->node_hash[hash]; tree->node_hash[hash] = node; tree->node_hash_cnt++; } else { <- Thread B spin_unlock(&tree->hash_lock); kfree(node); wait_event(node2->lock_wq, !test_bit(HFS_BNODE_NEW, &node2->flags)); return node2; }```However, hfs_bnode_find() requires each call to take a reference.Here both threads end up setting refcnt=1. When they later put the node,this triggers:BUG_ON(!atomic_read(&node->refcnt))In this scenario, Thread B in fact finds the node in the hash tablerather than creating a new one, and thus must take a reference.Fix this by calling hfs_bnode_get() when reusing a bnode newly created byanother thread to ensure the refcount is updated correctly.A similar bug was fixed in HFS long ago in commita9dc087fd3c4 ("fix missing hfs_bnode_get() in __hfs_bnode_create")but the same issue remained in HFS+ until now.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68788 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: do not generate ACCESS/MODIFY events on child for special filesinotify/fanotify do not allow users with no read access to a file tosubscribe to events (e.g. IN_ACCESS/IN_MODIFY), but they do allow thesame user to subscribe for watching events on children when the userhas access to the parent directory (e.g. /dev).Users with no read access to a file but with read access to its parentdirectory can still stat the file and see if it was accessed/modifiedvia atime/mtime change.The same is not true for special files (e.g. /dev/null). Users will notgenerally observe atime/mtime changes when other users read/write tospecial files, only when someone sets atime/mtime via utimensat().Align fsnotify events with this stat behavior and do not generateACCESS/MODIFY events to parent watchers on read/write of special files.The events are still generated to parent watchers on utimensat(). Thiscloses some side-channels that could be possibly used for informationexfiltration [1].[1] https://snee.la/pdf/pubs/file-notification-attacks.pdf

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68789 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (ibmpex) fix use-after-free in high/low storeThe ibmpex_high_low_store() function retrieves driver data usingdev_get_drvdata() and uses it without validation. This creates a racecondition where the sysfs callback can be invoked after the datastructure is freed, leading to use-after-free.Fix by adding a NULL check after dev_get_drvdata(), and reorderingoperations in the deletion path to prevent TOCTOU.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68820 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: xattr: fix null pointer deref in ext4_raw_inode()If ext4_get_inode_loc() fails (e.g. if it returns -EFSCORRUPTED),iloc.bh will remain set to NULL. Since ext4_xattr_inode_dec_ref_all()lacks error checking, this will lead to a null pointer dereferencein ext4_raw_inode(), called right after ext4_get_inode_loc().Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71097 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ipv4: Fix reference count leak when using error routes with nexthop objectsWhen a nexthop object is deleted, it is marked as dead and thenfib_table_flush() is called to flush all the routes that are using thedead nexthop.The current logic in fib_table_flush() is to only flush error routes(e.g., blackhole) when it is called as part of network namespacedismantle (i.e., with flush_all=true). Therefore, error routes are notflushed when their nexthop object is deleted: # ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1As such, they keep holding a reference on the nexthop object which inturn holds a reference on the nexthop device, resulting in a referencecount leak: # ip link del dev dummy1 [ 70.516258] unregister_netdevice: waiting for dummy1 to become free. Usage count = 2Fix by flushing error routes when their nexthop is marked as dead.IPv6 does not suffer from this problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8114 Severity: Moderate CVSS3 score: 4.7

Description: A flaw was found in libssh, a library that implements the SSH protocol. When calculating the session ID during the key exchange (KEX) process, an allocation failure in cryptographic functions may lead to a NULL pointer dereference. This issue can cause the client or server to crash.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.9.1).

CVE-2024-40635 Severity: Moderate CVSS3 score: 4.6

Description: containerd is an open-source container runtime. A bug was found in containerd prior to versions 1.6.38, 1.7.27, and 2.0.4 where containers launched with a User set as a `UID:GID` larger than the maximum 32-bit signed integer can cause an overflow condition where the container ultimately runs as root (UID 0). This could cause unexpected behavior for environments that require containers to run as a non-root user. This bug has been fixed in containerd 1.6.38, 1.7.27, and 2.04. As a workaround, ensure that only trusted images are used and that only trusted users have permissions to import images.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.27-150000.123.1).

CVE-2024-42226 Severity: Moderate CVSS3 score: 4.6

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21704 Severity: Moderate CVSS3 score: 4.6

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdc-acm: Check control transfer buffer size before accessIf the first fragment is shorter than struct usb_cdc_notification, we can'tcalculate an expected_size. Log an error and discard the notificationinstead of reading lengths from memory outside the received data, which canlead to memory corruption when the expected_size decreases betweenfragments, causing `expected_size - acm->nb_index` to wrap.This issue has been present since the beginning of git history; however,it only leads to memory corruption since commit ea2583529cd1("cdc-acm: reassemble fragmented notifications").A mitigating factor is that acm_ctrl_irq() can only execute after userspacehas opened /dev/ttyACM*; but if ModemManager is running, ModemManager willdo that automatically depending on the USB device's vendor/product IDs andits other interfaces.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38348 Severity: Moderate CVSS3 score: 4.6

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()Robert Morris reported:|If a malicious USB device pretends to be an Intersil p54 wifi|interface and generates an eeprom_readback message with a large|eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the|message beyond the end of priv->eeprom.||static void p54_rx_eeprom_readback(struct p54_common *priv,| struct sk_buff *skb)|{| struct p54_hdr *hdr = (struct p54_hdr *) skb->data;| struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data;|| if (priv->fw_var >= 0x509) {| memcpy(priv->eeprom, eeprom->v2.data,| le16_to_cpu(eeprom->v2.len));| } else {| memcpy(priv->eeprom, eeprom->v1.data,| le16_to_cpu(eeprom->v1.len));| }| [...]The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom().The device is supposed to provide the same length back to the driver.But yes, it's possible (like shown in the report) to alter the valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand no longer copies them.The one, small saving grace is: Before the driver tries to read the eeprom,it needs to upload >a< firmware. the vendor firmware has a proprietarylicense and as a reason, it is not present on most distributions bydefault.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49814 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:kcm: close race conditions on sk_receive_queuesk->sk_receive_queue is protected by skb queue lock, but for KCMsockets its RX path takes mux->rx_lock to protect more than justskb queue. However, kcm_recvmsg() still only grabs the skb queuelock, so race conditions still exist.We can teach kcm_recvmsg() to grab mux->rx_lock too but this wouldintroduce a potential performance regression as struct kcm_mux canbe shared by multiple KCM sockets.So we have to enforce skb queue lock in requeue_rx_msgs() and handleskb peek case carefully in kcm_wait_data(). Fortunately,skb_recv_datagram() already handles it nicely and is widely used byother sockets, we can just switch to skb_recv_datagram() aftergetting rid of the unnecessary sock lock in kcm_recvmsg() andkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,so it is safe to get rid of this check too.I ran the original syzbot reproducer for 30 min without seeing anyissue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52503 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix use-after-free vulnerability in amdtee_close_sessionThere is a potential race condition in amdtee_close_session that maycause use-after-free in amdtee_open_session. For instance, if a sessionhas refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session);the reference count will get decremented, and the next step would be tocall destroy_session(). However, if in another thread,amdtee_open_session() is called before destroy_session() has completedexecution, alloc_session() may return 'sess' that will be freed uplater in destroy_session() leading to use-after-free inamdtee_open_session.To fix this issue, treat decrement of sess->refcount and removal of'sess' from session list in destroy_session() as a critical section, sothat it is executed atomically.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-43790 Severity: Moderate CVSS3 score: 4.5

Description: Vim is an open source command line text editor. When performing a search and displaying the search-count message is disabled (:set shm+=S), the search pattern is displayed at the bottom of the screen in a buffer (msgbuf). When right-left mode (:set rl) is enabled, the search pattern is reversed. This happens by allocating a new buffer. If the search pattern contains some ASCII NUL characters, the buffer allocated will be smaller than the original allocated buffer (because for allocating the reversed buffer, the strlen() function is called, which only counts until it notices an ASCII NUL byte ) and thus the original length indicator is wrong. This causes an overflow when accessing characters inside the msgbuf by the previously (now wrong) length of the msgbuf. The issue has been fixed as of Vim patch v9.1.0689.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2024-43802 Severity: Moderate CVSS3 score: 4.5

Description: Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters. So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It's not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-0840 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as problematic, was found in GNU Binutils up to 2.43. This affects the function disassemble_bytes of the file binutils/objdump.c. The manipulation of the argument buf leads to stack-based buffer overflow. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. The identifier of the patch is baac6c221e9d69335bf41366a1c7d87d8ab2f893. It is recommended to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-11065 Severity: Moderate CVSS3 score: 4.5

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
docker > 0-0 (version in image is 28.3.3_ce-150000.230.1).

CVE-2025-1176 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability was found in GNU Binutils 2.43 and classified as critical. This issue affects the function _bfd_elf_gc_mark_rsec of the file elflink.c of the component ld. The manipulation leads to heap-based buffer overflow. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. The patch is named f9978defb6fab0bd8583942d97c112b0932ac814. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1182 Severity: Moderate CVSS3 score: 4.5

Description: A vulnerability, which was classified as critical, was found in GNU Binutils 2.43. Affected is the function bfd_elf_reloc_symbol_deleted_p of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. The patch is identified as b425859021d17adf62f06fb904797cf8642986ad. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-37920 Severity: Moderate CVSS3 score: 4.5

Description: In the Linux kernel, the following vulnerability has been resolved:xsk: Fix race condition in AF_XDP generic RX pathMove rx_lock from xsk_socket to xsk_buff_pool.Fix synchronization for shared umem mode ingeneric RX path where multiple sockets sharesingle xsk_buff_pool.RX queue is exclusive to xsk_socket, while FILLqueue can be shared between multiple sockets.This could result in race condition where twoCPU cores access RX path of two different socketssharing the same umem.Protect both queues by acquiring spinlock in sharedxsk_buff_pool.Lock contention may be minimized in the future by someper-thread FQ buffering.It's safe and necessary to move spin_lock_bh(rx_lock)after xsk_rcv_check():* xs->pool and spinlock_init is synchronized by xsk_bind() -> xsk_is_bound() memory barriers.* xsk_rcv_check() may return true at the moment of xsk_release() or xsk_unbind_dev(), however this will not cause any data races or race conditions. xsk_unbind_dev() removes xdp socket from all maps and waits for completion of all outstanding rx operations. Packets in RX path will either complete safely or drop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47572 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: nexthop: fix null pointer dereference when IPv6 is not enabledWhen we try to add an IPv6 nexthop and IPv6 is not enabled(!CONFIG_IPV6) we'll hit a NULL pointer dereference[1] in the error pathof nh_create_ipv6() due to calling ipv6_stub->fib6_nh_release. The bughas been present since the beginning of IPv6 nexthop gateway support.Commit 1aefd3de7bc6 ("ipv6: Add fib6_nh_init and release to stubs") tellsus that only fib6_nh_init has a dummy stub because fib6_nh_release shouldnot be called if fib6_nh_init returns an error, but the commit below addeda call to ipv6_stub->fib6_nh_release in its error path. To fix it returnthe dummy stub's -EAFNOSUPPORT error directly without callingipv6_stub->fib6_nh_release in nh_create_ipv6()'s error path.[1] Output is a bit truncated, but it clearly shows the error. BUG: kernel NULL pointer dereference, address: 000000000000000000 #PF: supervisor instruction fetch in kernel modede #PF: error_code(0x0010) - not-present pagege PGD 0 P4D 0 Oops: 0010 [#1] PREEMPT SMP NOPTI CPU: 4 PID: 638 Comm: ip Kdump: loaded Not tainted 5.16.0-rc1+ #446 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/01/2014 RIP: 0010:0x0 Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. RSP: 0018:ffff888109f5b8f0 EFLAGS: 00010286^Ac RAX: 0000000000000000 RBX: ffff888109f5ba28 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8881008a2860 RBP: ffff888109f5b9d8 R08: 0000000000000000 R09: 0000000000000000 R10: ffff888109f5b978 R11: ffff888109f5b948 R12: 00000000ffffff9f R13: ffff8881008a2a80 R14: ffff8881008a2860 R15: ffff8881008a2840 FS: 00007f98de70f100(0000) GS:ffff88822bf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffffffffd6 CR3: 0000000100efc000 CR4: 00000000000006e0 Call Trace: nh_create_ipv6+0xed/0x10c rtm_new_nexthop+0x6d7/0x13f3 ? check_preemption_disabled+0x3d/0xf2 ? lock_is_held_type+0xbe/0xfd rtnetlink_rcv_msg+0x23f/0x26a ? check_preemption_disabled+0x3d/0xf2 ? rtnl_calcit.isra.0+0x147/0x147 netlink_rcv_skb+0x61/0xb2 netlink_unicast+0x100/0x187 netlink_sendmsg+0x37f/0x3a0 ? netlink_unicast+0x187/0x187 sock_sendmsg_nosec+0x67/0x9b ____sys_sendmsg+0x19d/0x1f9 ? copy_msghdr_from_user+0x4c/0x5e ? rcu_read_lock_any_held+0x2a/0x78 ___sys_sendmsg+0x6c/0x8c ? asm_sysvec_apic_timer_interrupt+0x12/0x20 ? lockdep_hardirqs_on+0xd9/0x102 ? sockfd_lookup_light+0x69/0x99 __sys_sendmsg+0x50/0x6e do_syscall_64+0xcb/0xf2 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f98dea28914 Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 48 8d 05 e9 5d 0c 00 8b 00 85 c0 75 13 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 41 89 d4 55 48 89 f5 53 RSP: 002b:00007fff859f5e68 EFLAGS: 00000246 ORIG_RAX: 000000000000002e2e RAX: ffffffffffffffda RBX: 00000000619cb810 RCX: 00007f98dea28914 RDX: 0000000000000000 RSI: 00007fff859f5ed0 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000008 R10: fffffffffffffce6 R11: 0000000000000246 R12: 0000000000000001 R13: 000055c0097ae520 R14: 000055c0097957fd R15: 00007fff859f63a0 Modules linked in: bridge stp llc bonding virtio_net

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48850 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net-sysfs: add check for netdevice being present to speed_showWhen bringing down the netdevice or system shutdown, a panic can betriggered while accessing the sysfs path because the device is alreadyremoved. [ 755.549084] mlx5_core 0000:12:00.1: Shutdown was called [ 756.404455] mlx5_core 0000:12:00.0: Shutdown was called ... [ 757.937260] BUG: unable to handle kernel NULL pointer dereference at (null) [ 758.031397] IP: [] dma_pool_alloc+0x1ab/0x280 crash> bt ... PID: 12649 TASK: ffff8924108f2100 CPU: 1 COMMAND: "amsd" ... #9 [ffff89240e1a38b0] page_fault at ffffffff8f38c778 [exception RIP: dma_pool_alloc+0x1ab] RIP: ffffffff8ee11acb RSP: ffff89240e1a3968 RFLAGS: 00010046 RAX: 0000000000000246 RBX: ffff89243d874100 RCX: 0000000000001000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff89243d874090 RBP: ffff89240e1a39c0 R8: 000000000001f080 R9: ffff8905ffc03c00 R10: ffffffffc04680d4 R11: ffffffff8edde9fd R12: 00000000000080d0 R13: ffff89243d874090 R14: ffff89243d874080 R15: 0000000000000000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #10 [ffff89240e1a39c8] mlx5_alloc_cmd_msg at ffffffffc04680f3 [mlx5_core] #11 [ffff89240e1a3a18] cmd_exec at ffffffffc046ad62 [mlx5_core] #12 [ffff89240e1a3ab8] mlx5_cmd_exec at ffffffffc046b4fb [mlx5_core] #13 [ffff89240e1a3ae8] mlx5_core_access_reg at ffffffffc0475434 [mlx5_core] #14 [ffff89240e1a3b40] mlx5e_get_fec_caps at ffffffffc04a7348 [mlx5_core] #15 [ffff89240e1a3bb0] get_fec_supported_advertised at ffffffffc04992bf [mlx5_core] #16 [ffff89240e1a3c08] mlx5e_get_link_ksettings at ffffffffc049ab36 [mlx5_core] #17 [ffff89240e1a3ce8] __ethtool_get_link_ksettings at ffffffff8f25db46 #18 [ffff89240e1a3d48] speed_show at ffffffff8f277208 #19 [ffff89240e1a3dd8] dev_attr_show at ffffffff8f0b70e3 #20 [ffff89240e1a3df8] sysfs_kf_seq_show at ffffffff8eedbedf #21 [ffff89240e1a3e18] kernfs_seq_show at ffffffff8eeda596 #22 [ffff89240e1a3e28] seq_read at ffffffff8ee76d10 #23 [ffff89240e1a3e98] kernfs_fop_read at ffffffff8eedaef5 #24 [ffff89240e1a3ed8] vfs_read at ffffffff8ee4e3ff #25 [ffff89240e1a3f08] sys_read at ffffffff8ee4f27f #26 [ffff89240e1a3f50] system_call_fastpath at ffffffff8f395f92 crash> net_device.state ffff89443b0c0000 state = 0x5 (__LINK_STATE_START| __LINK_STATE_NOCARRIER)To prevent this scenario, we also make sure that the netdevice is present.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48957 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:dpaa2-switch: Fix memory leak in dpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove()The cmd_buff needs to be freed when error happened indpaa2_switch_acl_entry_add() and dpaa2_switch_acl_entry_remove().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49048 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: fix panic when forwarding a pkt with no in6 devkongweibin reported a kernel panic in ip6_forward() when input interfacehas no in6 dev associated.The following tc commands were used to reproduce this panic:tc qdisc del dev vxlan100 roottc qdisc add dev vxlan100 root netem corrupt 5%

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49932 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: VMX: Do _all_ initialization before exposing /dev/kvm to userspaceCall kvm_init() only after _all_ setup is complete, as kvm_init() exposes/dev/kvm to userspace and thus allows userspace to create VMs (and callother ioctls). E.g. KVM will encounter a NULL pointer when attempting toadd a vCPU to the per-CPU loaded_vmcss_on_cpu list if userspace is able tocreate a VM before vmx_init() configures said list. BUG: kernel NULL pointer dereference, address: 0000000000000008 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#1] SMP CPU: 6 PID: 1143 Comm: stable Not tainted 6.0.0-rc7+ #988 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:vmx_vcpu_load_vmcs+0x68/0x230 [kvm_intel] vmx_vcpu_load+0x16/0x60 [kvm_intel] kvm_arch_vcpu_load+0x32/0x1f0 [kvm] vcpu_load+0x2f/0x40 [kvm] kvm_arch_vcpu_create+0x231/0x310 [kvm] kvm_vm_ioctl+0x79f/0xe10 [kvm] ? handle_mm_fault+0xb1/0x220 __x64_sys_ioctl+0x80/0xb0 do_syscall_64+0x2b/0x50 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7f5a6b05743b Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel(+) kvm irqbypass

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50378 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/meson: reorder driver deinit sequence to fix use-after-free bugUnloading the driver triggers the following KASAN warning:[ +0.006275] =============================================================[ +0.000029] BUG: KASAN: use-after-free in __list_del_entry_valid+0xe0/0x1a0[ +0.000026] Read of size 8 at addr ffff000020c395e0 by task rmmod/2695[ +0.000019] CPU: 5 PID: 2695 Comm: rmmod Tainted: G C O 5.19.0-rc6-lrmbkasan+ #1[ +0.000013] Hardware name: Hardkernel ODROID-N2Plus (DT)[ +0.000008] Call trace:[ +0.000007] dump_backtrace+0x1ec/0x280[ +0.000013] show_stack+0x24/0x80[ +0.000008] dump_stack_lvl+0x98/0xd4[ +0.000011] print_address_description.constprop.0+0x80/0x520[ +0.000011] print_report+0x128/0x260[ +0.000007] kasan_report+0xb8/0xfc[ +0.000008] __asan_report_load8_noabort+0x3c/0x50[ +0.000010] __list_del_entry_valid+0xe0/0x1a0[ +0.000009] drm_atomic_private_obj_fini+0x30/0x200 [drm][ +0.000172] drm_bridge_detach+0x94/0x260 [drm][ +0.000145] drm_encoder_cleanup+0xa4/0x290 [drm][ +0.000144] drm_mode_config_cleanup+0x118/0x740 [drm][ +0.000143] drm_mode_config_init_release+0x1c/0x2c [drm][ +0.000144] drm_managed_release+0x170/0x414 [drm][ +0.000142] drm_dev_put.part.0+0xc0/0x124 [drm][ +0.000143] drm_dev_put+0x20/0x30 [drm][ +0.000142] meson_drv_unbind+0x1d8/0x2ac [meson_drm][ +0.000028] take_down_aggregate_device+0xb0/0x160[ +0.000016] component_del+0x18c/0x360[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi][ +0.000015] platform_remove+0x64/0xb0[ +0.000009] device_remove+0xb8/0x154[ +0.000009] device_release_driver_internal+0x398/0x5b0[ +0.000009] driver_detach+0xac/0x1b0[ +0.000009] bus_remove_driver+0x158/0x29c[ +0.000009] driver_unregister+0x70/0xb0[ +0.000008] platform_driver_unregister+0x20/0x2c[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi][ +0.000012] __do_sys_delete_module+0x288/0x400[ +0.000011] __arm64_sys_delete_module+0x5c/0x80[ +0.000009] invoke_syscall+0x74/0x260[ +0.000009] el0_svc_common.constprop.0+0xcc/0x260[ +0.000009] do_el0_svc+0x50/0x70[ +0.000007] el0_svc+0x68/0x1a0[ +0.000012] el0t_64_sync_handler+0x11c/0x150[ +0.000008] el0t_64_sync+0x18c/0x190[ +0.000018] Allocated by task 0:[ +0.000007] (stack is not available)[ +0.000011] Freed by task 2695:[ +0.000008] kasan_save_stack+0x2c/0x5c[ +0.000011] kasan_set_track+0x2c/0x40[ +0.000008] kasan_set_free_info+0x28/0x50[ +0.000009] ____kasan_slab_free+0x128/0x1d4[ +0.000008] __kasan_slab_free+0x18/0x24[ +0.000007] slab_free_freelist_hook+0x108/0x230[ +0.000011] kfree+0x110/0x35c[ +0.000008] release_nodes+0xf0/0x16c[ +0.000009] devres_release_group+0x180/0x270[ +0.000008] component_unbind+0x128/0x1e0[ +0.000010] component_unbind_all+0x1b8/0x264[ +0.000009] meson_drv_unbind+0x1a0/0x2ac [meson_drm][ +0.000025] take_down_aggregate_device+0xb0/0x160[ +0.000009] component_del+0x18c/0x360[ +0.000009] meson_dw_hdmi_remove+0x28/0x40 [meson_dw_hdmi][ +0.000012] platform_remove+0x64/0xb0[ +0.000008] device_remove+0xb8/0x154[ +0.000009] device_release_driver_internal+0x398/0x5b0[ +0.000009] driver_detach+0xac/0x1b0[ +0.000009] bus_remove_driver+0x158/0x29c[ +0.000008] driver_unregister+0x70/0xb0[ +0.000008] platform_driver_unregister+0x20/0x2c[ +0.000008] meson_dw_hdmi_platform_driver_exit+0x1c/0x30 [meson_dw_hdmi][ +0.000011] __do_sys_delete_module+0x288/0x400[ +0.000010] __arm64_sys_delete_module+0x5c/0x80[ +0.000008] invoke_syscall+0x74/0x260[ +0.000008] el0_svc_common.constprop.0+0xcc/0x260[ +0.000008] do_el0_svc+0x50/0x70[ +0.000007] el0_svc+0x68/0x1a0[ +0.000009] el0t_64_sync_handler+0x11c/0x150[ +0.000009] el0t_64_sync+0x18c/0x190[ +0.000014] The buggy address belongs to the object at ffff000020c39000---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50491 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: cti: Fix hang in cti_disable_hw()cti_enable_hw() and cti_disable_hw() are called from an atomic contextso shouldn't use runtime PM because it can result in a sleep whencommunicating with firmware.Since commit 3c6656337852 ("Revert "firmware: arm_scmi: Add clockmanagement to the SCMI power domain""), this causes a hang on Juno whenrunning the Perf Coresight tests or running this command: perf record -e cs_etm//u -- lsThis was also missed until the revert commit because pm_runtime_put()was called with the wrong device until commit 692c9a499b28 ("coresight:cti: Correct the parameter for pm_runtime_put")With lock and scheduler debugging enabled the following is output: coresight cti_sys0: cti_enable_hw -- dev:cti_sys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 330, name: perf-exec preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [] copy_process+0xa0c/0x1948 softirqs last enabled at (0): [] copy_process+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dump_backtrace+0x134/0x140 show_stack+0x20/0x58 dump_stack_lvl+0x8c/0xb8 dump_stack+0x18/0x34 __might_resched+0x180/0x228 __might_sleep+0x50/0x88 __pm_runtime_resume+0xac/0xb0 cti_enable+0x44/0x120 coresight_control_assoc_ectdev+0xc0/0x150 coresight_enable_path+0xb4/0x288 etm_event_start+0x138/0x170 etm_event_add+0x48/0x70 event_sched_in.isra.122+0xb4/0x280 merge_sched_in+0x1fc/0x3d0 visit_groups_merge.constprop.137+0x16c/0x4b0 ctx_sched_in+0x114/0x1f0 perf_event_sched_in+0x60/0x90 ctx_resched+0x68/0xb0 perf_event_exec+0x138/0x508 begin_new_exec+0x52c/0xd40 load_elf_binary+0x6b8/0x17d0 bprm_execve+0x360/0x7f8 do_execveat_common.isra.47+0x218/0x238 __arm64_sys_execve+0x48/0x60 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.4+0xfc/0x120 do_el0_svc+0x34/0xc0 el0_svc+0x40/0x98 el0t_64_sync_handler+0x98/0xc0 el0t_64_sync+0x170/0x174Fix the issue by removing the runtime PM calls completely. They are notneeded here because it must have already been done when building thepath for a trace.[ Fix build warnings ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50493 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix crash when I/O abort times outWhile performing CPU hotplug, a crash with the following stack was seen:Call Trace: qla24xx_process_response_queue+0x42a/0x970 [qla2xxx] qla2x00_start_nvme_mq+0x3a2/0x4b0 [qla2xxx] qla_nvme_post_cmd+0x166/0x240 [qla2xxx] nvme_fc_start_fcp_op.part.0+0x119/0x2e0 [nvme_fc] blk_mq_dispatch_rq_list+0x17b/0x610 __blk_mq_sched_dispatch_requests+0xb0/0x140 blk_mq_sched_dispatch_requests+0x30/0x60 __blk_mq_run_hw_queue+0x35/0x90 __blk_mq_delay_run_hw_queue+0x161/0x180 blk_execute_rq+0xbe/0x160 __nvme_submit_sync_cmd+0x16f/0x220 [nvme_core] nvmf_connect_admin_queue+0x11a/0x170 [nvme_fabrics] nvme_fc_create_association.cold+0x50/0x3dc [nvme_fc] nvme_fc_connect_ctrl_work+0x19/0x30 [nvme_fc] process_one_work+0x1e8/0x3c0On abort timeout, completion was called without checking if the I/O wasalready completed.Verify that I/O and abort request are indeed outstanding before attemptingcompletion.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50498 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:eth: alx: take rtnl_lock on resumeZbynek reports that alx trips an rtnl assertion on resume: RTNL: assertion failed at net/core/dev.c (2891) RIP: 0010:netif_set_real_num_tx_queues+0x1ac/0x1c0 Call Trace: __alx_open+0x230/0x570 [alx] alx_resume+0x54/0x80 [alx] ? pci_legacy_resume+0x80/0x80 dpm_run_callback+0x4a/0x150 device_resume+0x8b/0x190 async_resume+0x19/0x30 async_run_entry_fn+0x30/0x130 process_one_work+0x1e5/0x3b0indeed the driver does not hold rtnl_lock during its internal closeand re-open functions during suspend/resume. Note that this is nota huge bug as the driver implements its own locking, and does notimplement changing the number of queues, but we need to silencethe splat.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50519 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: replace WARN_ONs by nilfs_error for checkpoint acquisition failureIf creation or finalization of a checkpoint fails due to anomalies in thecheckpoint metadata on disk, a kernel warning is generated.This patch replaces the WARN_ONs by nilfs_error, so that a kernel, bootedwith panic_on_warn, does not panic. A nilfs_error is appropriate here tohandle the abnormal filesystem condition.This also replaces the detected error codes with an I/O error so thatneither of the internal error codes is returned to callers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50651 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: eeprom: fix null-deref on genl_info in dumpThe similar fix as commit 46cdedf2a0fa ("ethtool: pse-pd: fix null-deref ongenl_info in dump") is also needed for ethtool eeprom.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50816 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: ensure sane device mtu in tunnelsAnother syzbot report [1] with no reproducer hintsat a bug in ip6_gre tunnel (dev:ip6gretap0)Since ipv6 mcast code makes sure to read dev->mtu onceand applies a sanity check on it (see commit b9b312a7a451"ipv6: mcast: better catch silly mtu values"), a remainingpossibility is that a layer is able to set dev->mtu toan underflowed value (high order bit set).This could happen indeed in ip6gre_tnl_link_config_route(),ip6_tnl_link_config() and ipip6_tunnel_bind_dev()Make sure to sanitize mtu value in a local variable beforeit is written once on dev->mtu, as lockless readers couldcatch wrong temporary value.[1]skbuff: skb_over_panic: text:ffff80000b7a2f38 len:40 put:40 head:ffff000149dcf200 data:ffff000149dcf2b0 tail:0xd8 end:0xc0 dev:ip6gretap0------------[ cut here ]------------kernel BUG at net/core/skbuff.c:120Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 10241 Comm: kworker/1:1 Not tainted 6.0.0-rc7-syzkaller-18095-gbbed346d5a96 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/30/2022Workqueue: mld mld_ifc_workpstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : skb_panic+0x4c/0x50 net/core/skbuff.c:116lr : skb_panic+0x4c/0x50 net/core/skbuff.c:116sp : ffff800020dd3b60x29: ffff800020dd3b70 x28: 0000000000000000 x27: ffff00010df2a800x26: 00000000000000c0 x25: 00000000000000b0 x24: ffff000149dcf200x23: 00000000000000c0 x22: 00000000000000d8 x21: ffff80000b7a2f38x20: ffff00014c2f7800 x19: 0000000000000028 x18: 00000000000001a9x17: 0000000000000000 x16: ffff80000db49158 x15: ffff000113bf1a80x14: 0000000000000000 x13: 00000000ffffffff x12: ffff000113bf1a80x11: ff808000081c0d5c x10: 0000000000000000 x9 : 73f125dc5c63ba00x8 : 73f125dc5c63ba00 x7 : ffff800008161d1c x6 : 0000000000000000x5 : 0000000000000080 x4 : 0000000000000001 x3 : 0000000000000000x2 : ffff0001fefddcd0 x1 : 0000000100000000 x0 : 0000000000000089Call trace:skb_panic+0x4c/0x50 net/core/skbuff.c:116skb_over_panic net/core/skbuff.c:125 [inline]skb_put+0xd4/0xdc net/core/skbuff.c:2049ip6_mc_hdr net/ipv6/mcast.c:1714 [inline]mld_newpack+0x14c/0x270 net/ipv6/mcast.c:1765add_grhead net/ipv6/mcast.c:1851 [inline]add_grec+0xa20/0xae0 net/ipv6/mcast.c:1989mld_send_cr+0x438/0x5a8 net/ipv6/mcast.c:2115mld_ifc_work+0x38/0x290 net/ipv6/mcast.c:2653process_one_work+0x2d8/0x504 kernel/workqueue.c:2289worker_thread+0x340/0x610 kernel/workqueue.c:2436kthread+0x12c/0x158 kernel/kthread.c:376ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Code: 91011400 aa0803e1 a90027ea 94373093 (d4210000)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-40546 Severity: Moderate CVSS3 score: 4.4

Description: A flaw was found in Shim when an error happened while creating a new ESL variable. If Shim fails to create the new variable, it tries to print an error message to the user; however, the number of parameters used by the logging function doesn't match the format string used by it, leading to a crash under certain circumstances.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-40549 Severity: Moderate CVSS3 score: 4.4

Description: An out-of-bounds read flaw was found in Shim due to the lack of proper boundary verification during the load of a PE binary. This flaw allows an attacker to load a crafted PE binary, triggering the issue and crashing Shim, resulting in a denial of service.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-40551 Severity: Moderate CVSS3 score: 4.4

Description: A flaw was found in the MZ binary format in Shim. An out-of-bounds read may occur, leading to a crash or possible exposure of sensitive data during the system's boot phase.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2023-46838 Severity: Moderate CVSS3 score: 4.4

Description: Transmit requests in Xen's virtual network protocol can consist ofmultiple parts. While not really useful, except for the initial partany of them may be of zero length, i.e. carry no data at all. Besides acertain initial portion of the to be transferred data, these parts aredirectly translated into what Linux calls SKB fragments. Such convertedrequest parts can, when for a particular SKB they are all of lengthzero, lead to a de-reference of NULL in core networking code.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52595 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rt2x00: restart beacon queue when hardware resetWhen a hardware reset is triggered, all registers are reset, so allqueues are forced to stop in hardware interface. However, mac80211will not automatically stop the queue. If we don't manually stop thebeacon queue, the queue will be deadlocked and unable to start again.This patch fixes the issue where Apple devices cannot connect to theAP after calling ieee80211_restart_hw().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52614 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:PM / devfreq: Fix buffer overflow in trans_stat_showFix buffer overflow in trans_stat_show().Convert simple snprintf to the more secure scnprintf with size ofPAGE_SIZE.Add condition checking if we are exceeding PAGE_SIZE and exit early fromloop. Also add at the end a warning that we exceeded PAGE_SIZE and thatstats is disabled.Return -EFBIG in the case where we don't have enough space to write thefull transition table.Also document in the ABI that this function can return -EFBIG error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52618 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:block/rnbd-srv: Check for unlikely string overflowSince "dev_search_path" can technically be as large as PATH_MAX,there was a risk of truncation when copying it and a second stringinto "full_path" since it was also PATH_MAX sized. The W=1 builds werereporting this warning:drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=] 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~In function 'rnbd_srv_get_full_path', inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096 616 | snprintf(full_path, PATH_MAX, "%s/%s", | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 617 | dev_search_path, dev_name); | ~~~~~~~~~~~~~~~~~~~~~~~~~~To fix this, unconditionally check for truncation (as was already donefor the case where "%SESSNAME%" was present).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52622 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid online resizing failures due to oversized flex bgWhen we online resize an ext4 filesystem with a oversized flexbg_size, mkfs.ext4 -F -G 67108864 $dev -b 4096 100M mount $dev $dir resize2fs $dev 16Gthe following WARN_ON is triggered:==================================================================WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550Modules linked in: sg(E)CPU: 0 PID: 427 Comm: resize2fs Tainted: G E 6.6.0-rc5+ #314RIP: 0010:__alloc_pages+0x411/0x550Call Trace: __kmalloc_large_node+0xa2/0x200 __kmalloc+0x16e/0x290 ext4_resize_fs+0x481/0xd80 __ext4_ioctl+0x1616/0x1d90 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0xf0/0x150 do_syscall_64+0x3b/0x90==================================================================This is because flexbg_size is too large and the size of the new_group_dataarray to be allocated exceeds MAX_ORDER. Currently, the minimum value ofMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the correspondingmaximum number of groups that can be allocated is: (PAGE_SIZE << MAX_ORDER) / sizeof(struct ext4_new_group_data) ~ 21845And the value that is down-aligned to the power of 2 is 16384. Therefore,this value is defined as MAX_RESIZE_BG, and the number of groups addedeach time does not exceed this value during resizing, and is added multipletimes to complete the online resizing. The difference is that the metadatain a flex_bg may be more dispersed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52884 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Input: cyapa - add missing input core locking to suspend/resume functionsGrab input->mutex during suspend/resume functions like it is done inother input drivers. This fixes the following warning during systemsuspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:------------[ cut here ]------------WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6cModules linked in: ...CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109Hardware name: Samsung Exynos (Flattened Device Tree)Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28Exception stack(0xf1625fb0 to 0xf1625ff8)...---[ end trace 0000000000000000 ]---...------------[ cut here ]------------WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6cModules linked in: ...CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G W 6.6.0-rc5-next-20231009 #14109Hardware name: Samsung Exynos (Flattened Device Tree)Workqueue: events_unbound async_run_entry_fn unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x58/0x70 dump_stack_lvl from __warn+0x1a8/0x1cc __warn from warn_slowpath_fmt+0x18c/0x1b4 warn_slowpath_fmt from input_device_enabled+0x68/0x6c input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c cyapa_reinitialize from cyapa_resume+0x48/0x98 cyapa_resume from dpm_run_callback+0x90/0x298 dpm_run_callback from device_resume+0xb4/0x258 device_resume from async_resume+0x20/0x64 async_resume from async_run_entry_fn+0x40/0x15c async_run_entry_fn from process_scheduled_works+0xbc/0x6a8 process_scheduled_works from worker_thread+0x188/0x454 worker_thread from kthread+0x108/0x140 kthread from ret_from_fork+0x14/0x28Exception stack(0xf1625fb0 to 0xf1625ff8)...---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53357 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid10: check slab-out-of-bounds in md_bitmap_get_counterIf we write a large number to md/bitmap_set_bits, md_bitmap_checkpage()will return -EINVAL because 'page >= bitmap->pages', but the return valuewas not checked immediately in md_bitmap_get_counter() in order to set*blocks value and slab-out-of-bounds occurs.Move check of 'page >= bitmap->pages' to md_bitmap_get_counter() andreturn directly if true.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53442 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ice: Block switchdev mode when ADQ is active and vice versaADQ and switchdev are not supported simultaneously. Enabling both at thesame time can result in nullptr dereference.To prevent this, check if ADQ is active when changing devlink mode toswitchdev mode, and check if switchdev is active when enabling ADQ.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53503 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: allow ext4_get_group_info() to failPreviously, ext4_get_group_info() would treat an invalid group numberas BUG(), since in theory it should never happen. However, if amalicious attaker (or fuzzer) modifies the superblock via the blockdevice while it is the file system is mounted, it is possible fors_first_data_block to get set to a very large number. In that case,when calculating the block group of some block number (such as thestarting block of a preallocation region), could result in anunderflow and very large block group number. Then the BUG_ON check inext4_get_group_info() would fire, resutling in a denial of serviceattack that can be triggered by root or someone with write access tothe block device.For a quality of implementation perspective, it's best that even ifthe system administrator does something that they shouldn't, that itwill not trigger a BUG. So instead of BUG'ing, ext4_get_group_info()will call ext4_error and return NULL. We also add fallback code inall of the callers of ext4_get_group_info() that it might NULL.Also, since ext4_get_group_info() was already borderline to be aninline function, un-inline it. The results in a next reduction of thecompiled text size of ext4 by roughly 2k.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53588 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: check for station first in client probeWhen probing a client, first check if we have it, and thencheck for the channel context, otherwise you can triggerthe warning there easily by probing when the AP isn't evenstarted yet. Since a client existing means the AP is alsooperating, we can then keep the warning.Also simplify the moved code a bit.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53654 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: Add validation before accessing cgx and lmacwith the addition of new MAC blocks like CN10K RPM and CN10KBRPM_USX, LMACs are noncontiguous and CGX blocks are alsononcontiguous. But during RVU driver initialization, the driveris assuming they are contiguous and trying to accesscgx or lmac with their id which is resulting in kernel panic.This patch fixes the issue by adding proper checks.[ 23.219150] pc : cgx_lmac_read+0x38/0x70[ 23.219154] lr : rvu_program_channels+0x3f0/0x498[ 23.223852] sp : ffff000100d6fc80[ 23.227158] x29: ffff000100d6fc80 x28: ffff00010009f880 x27:000000000000005a[ 23.234288] x26: ffff000102586768 x25: 0000000000002500 x24:fffffffffff0f000

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53655 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:rcu: Avoid stack overflow due to __rcu_irq_enter_check_tick() being kprobe-edRegistering a kprobe on __rcu_irq_enter_check_tick() can cause kernelstack overflow as shown below. This issue can be reproduced by enablingCONFIG_NO_HZ_FULL and booting the kernel with argument "nohz_full=",and then giving the following commands at the shell prompt: # cd /sys/kernel/tracing/ # echo 'p:mp1 __rcu_irq_enter_check_tick' >> kprobe_events # echo 1 > events/kprobes/enableThis commit therefore adds __rcu_irq_enter_check_tick() to the kprobesblacklist using NOKPROBE_SYMBOL().Insufficient stack space to handle exception!ESR: 0x00000000f2000004 -- BRK (AArch64)FAR: 0x0000ffffccf3e510Task stack: [0xffff80000ad30000..0xffff80000ad38000]IRQ stack: [0xffff800008050000..0xffff800008058000]Overflow stack: [0xffff089c36f9f310..0xffff089c36fa0310]CPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)pstate: 400003c5 (nZcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __rcu_irq_enter_check_tick+0x0/0x1b8lr : ct_nmi_enter+0x11c/0x138sp : ffff80000ad30080x29: ffff80000ad30080 x28: ffff089c82e20000 x27: 0000000000000000x26: 0000000000000000 x25: ffff089c02a8d100 x24: 0000000000000000x23: 00000000400003c5 x22: 0000ffffccf3e510 x21: ffff089c36fae148x20: ffff80000ad30120 x19: ffffa8da8fcce148 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: ffffa8da8e44ea6cx14: ffffa8da8e44e968 x13: ffffa8da8e03136c x12: 1fffe113804d6809x11: ffff6113804d6809 x10: 0000000000000a60 x9 : dfff800000000000x8 : ffff089c026b404f x7 : 00009eec7fb297f7 x6 : 0000000000000001x5 : ffff80000ad30120 x4 : dfff800000000000 x3 : ffffa8da8e3016f4x2 : 0000000000000003 x1 : 0000000000000000 x0 : 0000000000000000Kernel panic - not syncing: kernel stack overflowCPU: 5 PID: 190 Comm: bash Not tainted 6.2.0-rc2-00320-g1f5abbd77e2c #19Hardware name: linux,dummy-virt (DT)Call trace: dump_backtrace+0xf8/0x108 show_stack+0x20/0x30 dump_stack_lvl+0x68/0x84 dump_stack+0x1c/0x38 panic+0x214/0x404 add_taint+0x0/0xf8 panic_bad_stack+0x144/0x160 handle_bad_stack+0x38/0x58 __bad_stack+0x78/0x7c __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 [...] el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 arm64_enter_el1_dbg.isra.0+0x14/0x20 el1_dbg+0x2c/0x90 el1h_64_sync_handler+0xcc/0xe8 el1h_64_sync+0x64/0x68 __rcu_irq_enter_check_tick+0x0/0x1b8 el1_interrupt+0x28/0x60 el1h_64_irq_handler+0x18/0x28 el1h_64_irq+0x64/0x68 __ftrace_set_clr_event_nolock+0x98/0x198 __ftrace_set_clr_event+0x58/0x80 system_enable_write+0x144/0x178 vfs_write+0x174/0x738 ksys_write+0xd0/0x188 __arm64_sys_write+0x4c/0x60 invoke_syscall+0x64/0x180 el0_svc_common.constprop.0+0x84/0x160 do_el0_svc+0x48/0xe8 el0_svc+0x34/0xd0 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x190/0x194SMP: stopping secondary CPUsKernel Offset: 0x28da86000000 from 0xffff800008000000PHYS_OFFSET: 0xfffff76600000000CPU features: 0x00000,01a00100,0000421bMemory Limit: none

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53668 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix deadloop issue on reading trace_pipeSoft lockup occurs when reading file 'trace_pipe': watchdog: BUG: soft lockup - CPU#6 stuck for 22s! [cat:4488] [...] RIP: 0010:ring_buffer_empty_cpu+0xed/0x170 RSP: 0018:ffff88810dd6fc48 EFLAGS: 00000246 RAX: 0000000000000000 RBX: 0000000000000246 RCX: ffffffff93d1aaeb RDX: ffff88810a280040 RSI: 0000000000000008 RDI: ffff88811164b218 RBP: ffff88811164b218 R08: 0000000000000000 R09: ffff88815156600f R10: ffffed102a2acc01 R11: 0000000000000001 R12: 0000000051651901 R13: 0000000000000000 R14: ffff888115e49500 R15: 0000000000000000 [...] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8d853c2000 CR3: 000000010dcd8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __find_next_entry+0x1a8/0x4b0 ? peek_next_entry+0x250/0x250 ? down_write+0xa5/0x120 ? down_write_killable+0x130/0x130 trace_find_next_entry_inc+0x3b/0x1d0 tracing_read_pipe+0x423/0xae0 ? tracing_splice_read_pipe+0xcb0/0xcb0 vfs_read+0x16b/0x490 ksys_read+0x105/0x210 ? __ia32_sys_pwrite64+0x200/0x200 ? switch_fpu_return+0x108/0x220 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x61/0xc6Through the vmcore, I found it's because in tracing_read_pipe(),ring_buffer_empty_cpu() found some buffer is not empty but then itcannot read anything due to "rb_num_of_entries() == 0" always true,Then it infinitely loop the procedure due to user buffer not beenfilled, see following code path: tracing_read_pipe() { ... ... waitagain: tracing_wait_pipe() // 1. find non-empty buffer here trace_find_next_entry_inc() // 2. loop here try to find an entry __find_next_entry() ring_buffer_empty_cpu(); // 3. find non-empty buffer peek_next_entry() // 4. but peek always return NULL ring_buffer_peek() rb_buffer_peek() rb_get_reader_page() // 5. because rb_num_of_entries() == 0 always true here // then return NULL // 6. user buffer not been filled so goto 'waitgain' // and eventually leads to an deadloop in kernel!!! }By some analyzing, I found that when resetting ringbuffer, the 'entries'of its pages are not all cleared (see rb_reset_cpu()). Then when reducingthe ringbuffer, and if some reduced pages exist dirty 'entries' data, theywill be added into 'cpu_buffer->overrun' (see rb_remove_pages()), whichcause wrong 'overrun' count and eventually cause the deadloop issue.To fix it, we need to clear every pages in rb_reset_cpu().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53681 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: Fix __bch_btree_node_alloc to make the failure behavior consistentIn some specific situations, the return value of __bch_btree_node_allocmay be NULL. This may lead to a potential NULL pointer dereference incaller function like a calling chain :btree_split->bch_btree_node_alloc->__bch_btree_node_alloc.Fix it by initializing the return value in __bch_btree_node_alloc.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53995 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv4: fix one memleak in __inet_del_ifa()I got the below warning when do fuzzing test:unregister_netdevice: waiting for bond0 to become free. Usage count = 2It can be repoduced via:ip link add bond0 type bondsysctl -w net.ipv4.conf.bond0.promote_secondaries=1ip addr add 4.117.174.103/0 scope 0x40 dev bond0ip addr add 192.168.100.111/255.255.255.254 scope 0 dev bond0ip addr add 0.0.0.4/0 scope 0x40 secondary dev bond0ip addr del 4.117.174.103/0 scope 0x40 dev bond0ip link delete bond0 type bondIn this reproduction test case, an incorrect 'last_prim' is found in__inet_del_ifa(), as a result, the secondary address(0.0.0.4/0 scope 0x40)is lost. The memory of the secondary address is leaked and the reference ofin_device and net_device is leaked.Fix this problem:Look for 'last_prim' starting at location of the deleted IP and insertingthe promoted IP into the location of 'last_prim'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7042 Severity: Moderate CVSS3 score: 4.4

Description: A null pointer dereference vulnerability was found in ath10k_wmi_tlv_op_pull_mgmt_tx_compl_ev() in drivers/net/wireless/ath/ath10k/wmi-tlv.c in the Linux kernel. This issue could be exploited to trigger a denial of service.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7192 Severity: Moderate CVSS3 score: 4.4

Description: A memory leak problem was found in ctnetlink_create_conntrack in net/netfilter/nf_conntrack_netlink.c in the Linux Kernel. This issue may allow a local attacker with CAP_NET_ADMIN privileges to cause a denial of service (DoS) attack due to a refcount overflow.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0841 Severity: Moderate CVSS3 score: 4.4

Description: A null pointer dereference flaw was found in the hugetlbfs_fill_super function in the Linux kernel hugetlbfs (HugeTLB pages) functionality. This issue may allow a local user to crash the system or potentially escalate their privileges on the system.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-23851 Severity: Moderate CVSS3 score: 4.4

Description: copy_params in drivers/md/dm-ioctl.c in the Linux kernel through 6.7.1 can attempt to allocate more than INT_MAX bytes, and crash, because of a missing param_kernel->data_size check. This is related to ctl_ioctl.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-25629 Severity: Moderate CVSS3 score: 4.4

Description: c-ares is a C library for asynchronous DNS requests. `ares__read_line()` is used to parse local configuration files such as `/etc/resolv.conf`, `/etc/nsswitch.conf`, the `HOSTALIASES` file, and if using a c-ares version prior to 1.27.0, the `/etc/hosts` file. If any of these configuration files has an embedded `NULL` character as the first character in a new line, it can lead to attempting to read memory prior to the start of the given buffer which may result in a crash. This issue is fixed in c-ares 1.27.0. No known workarounds exist.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libcares2 > 0-0 (version in image is 1.19.1-150000.3.26.1).

CVE-2024-26810 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl. Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate. For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured. A subsequent patch introduces synchronization forthe latter flows.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26812 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Create persistent INTx handlerA vulnerability exists where the eventfd for INTx signaling can bedeconfigured, which unregisters the IRQ handler but still allowseventfds to be signaled with a NULL context through the SET_IRQS ioctlor through unmask irqfd if the device interrupt is pending.Ideally this could be solved with some additional locking; the igatemutex serializes the ioctl and config space accesses, and the interrupthandler is unregistered relative to the trigger, but the irqfd pathruns asynchronous to those. The igate mutex cannot be acquired from theatomic context of the eventfd wake function. Disabling the irqfdrelative to the eventfd registration is potentially incompatible withexisting userspace.As a result, the solution implemented here moves configuration of theINTx interrupt handler to track the lifetime of the INTx context objectand irq_type configuration, rather than registration of a particulartrigger eventfd. Synchronization is added between the ioctl path andeventfd_signal() wrapper such that the eventfd trigger can bedynamically updated relative to in-flight interrupts or irqfd callbacks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26820 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missedIf hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTERhandler cannot perform VF register successfully as the register callis received before netvsc_probe is finished. This is because weregister register_netdevice_notifier() very early( even beforevmbus_driver_register()).To fix this, we try to register each such matching VF( if it is visibleas a netdevice) at the end of netvsc_probe.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26993 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fs: sysfs: Fix reference leak in sysfs_break_active_protection()The sysfs_break_active_protection() routine has an obvious referenceleak in its error path. If the call to kernfs_find_and_get() fails thenkn will be NULL, so the companion sysfs_unbreak_active_protection()routine won't get called (and would only cause an access violation bytrying to dereference kn->parent if it was called). As a result, thereference to kobj acquired at the start of the function will never bereleased.Fix the leak by adding an explicit kobject_put() call when kn is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-31076 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offlineThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness ofinterrupt affinity reconfiguration via procfs. Instead, the change isdeferred until the next instance of the interrupt being triggered on theoriginal CPU.When the interrupt next triggers on the original CPU, the new affinity isenforced within __irq_move_irq(). A vector is allocated from the new CPU,but the old vector on the original CPU remains and is not immediatelyreclaimed. Instead, apicd->move_in_progress is flagged, and the reclaimingprocess is delayed until the next trigger of the interrupt on the new CPU.Upon the subsequent triggering of the interrupt on the new CPU,irq_complete_move() adds a task to the old CPU's vector_cleanup list if itremains online. Subsequently, the timer on the old CPU iterates over itsvector_cleanup list, reclaiming old vectors.However, a rare scenario arises if the old CPU is outgoing before theinterrupt triggers again on the new CPU.In that case irq_force_complete_move() is not invoked on the outgoing CPUto reclaim the old apicd->prev_vector because the interrupt isn't currentlyaffine to the outgoing CPU, and irq_needs_fixup() returns false. Eventhough __vector_schedule_cleanup() is later called on the new CPU, itdoesn't reclaim apicd->prev_vector; instead, it simply resets bothapicd->move_in_progress and apicd->prev_vector to 0.As a result, the vector remains unreclaimed in vector_matrix, leading to aCPU vector leak.To address this issue, move the invocation of irq_force_complete_move()before the irq_needs_fixup() call to reclaim apicd->prev_vector, if theinterrupt is currently or used to be affine to the outgoing CPU.Additionally, reclaim the vector in __vector_schedule_cleanup() as well,following a warning message, although theoretically it should never seeapicd->move_in_progress with apicd->prev_cpu pointing to an offline CPU.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37891 Severity: Moderate CVSS3 score: 4.4

Description: urllib3 is a user-friendly HTTP client library for Python. When using urllib3's proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3's proxy support, it's possible to accidentally configure the `Proxy-Authorization` header even though it won't have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn't treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn't strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3's proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren't using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3's built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3's `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

CVE-2024-38546 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm: vc4: Fix possible null pointer dereferenceIn vc4_hdmi_audio_init() of_get_address() may returnNULL which is later dereferenced. Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38547 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binariesThe allocation failure of mycs->yuv_scaler_binary in load_video_binaries()is followed with a dereference of mycs->yuv_scaler_binary after thefollowing call chain:sh_css_pipe_load_binaries() |-> load_video_binaries(mycs->yuv_scaler_binary == NULL) | |-> sh_css_pipe_unload_binaries() |-> unload_video_binaries()In unload_video_binaries(), it calls to ia_css_binary_unload with argument&pipe->pipe_settings.video.yuv_scaler_binary[i], which refers to thesame memory slot as mycs->yuv_scaler_binary. Thus, a null-pointerdereference is triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38550 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: kirkwood: Fix potential NULL dereferenceIn kirkwood_dma_hw_params() mv_mbus_dram_info() returns NULL ifCONFIG_PLAT_ORION macro is not defined.Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38558 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix overwriting ct original tuple for ICMPv6OVS_PACKET_CMD_EXECUTE has 3 main attributes: - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format. - OVS_PACKET_ATTR_PACKET - Binary packet content. - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structurewith the metadata like conntrack state, input port, recirculation id,etc. Then the packet itself gets parsed to populate the rest of thekeys from the packet headers.Whenever the packet parsing code starts parsing the ICMPv6 header, itfirst zeroes out fields in the key corresponding to Neighbor Discoveryinformation even if it is not an ND packet.It is an 'ipv6.nd' field. However, the 'ipv6' is a union that sharesthe space between 'nd' and 'ct_orig' that holds the original tupleconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.ND packets should not normally have conntrack state, so it's fine toshare the space, but normal ICMPv6 Echo packets or maybe other types ofICMPv6 can have the state attached and it should not be overwritten.The issue results in all but the last 4 bytes of the destinationaddress being wiped from the original conntrack tuple leading toincorrect packet matching and potentially executing wrong actionsin case this packet recirculates within the datapath or goes backto userspace.ND fields should not be accessed in non-ND packets, so not clearingthem should be fine. Executing memset() only for actual ND packets toavoid the issue.Initializing the whole thing before parsing is needed because ND packetmay not contain all the options.The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn'taffect packets entering OVS datapath from network interfaces, becausein this case CT metadata is populated from skb after the packet isalready parsed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38571 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:thermal/drivers/tsens: Fix null pointer dereferencecompute_intercept_slope() is called from calibrate_8960() (in tsens-8960.c)as compute_intercept_slope(priv, p1, NULL, ONE_PT_CALIB) which lead to nullpointer dereference (if DEBUG or DYNAMIC_DEBUG set).Fix this bug by adding null pointer check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38580 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:epoll: be better about file lifetimesepoll can call out to vfs_poll() with a file pointer that may race withthe last 'fput()'. That would make f_count go down to zero, and whilethe ep->mtx locking means that the resulting file pointer tear-down willbe blocked until the poll returns, it means that f_count is alreadydead, and any use of it won't actually get a reference to the file anymore: it's dead regardless.Make sure we have a valid ref on the file pointer before we call down tovfs_poll() from the epoll routines.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38597 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:eth: sungem: remove .ndo_poll_controller to avoid deadlocksErhard reports netpoll warnings from sungem: netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20cgem_poll_controller() disables interrupts, which may sleep.We can't sleep in netpoll, it has interrupts disabled completely.Strangely, gem_poll_controller() doesn't even poll the completions,and instead acts as if an interrupt has fired so it just schedulesNAPI and exits. None of this has been necessary for years, sincenetpoll invokes NAPI directly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38605 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: core: Fix NULL module pointer assignment at card initThe commit 81033c6b584b ("ALSA: core: Warn on empty module")introduced a WARN_ON() for a NULL module pointer passed at snd_cardobject creation, and it also wraps the code around it with '#ifdefMODULE'. This works in most cases, but the devils are always indetails. "MODULE" is defined when the target code (i.e. the soundcore) is built as a module; but this doesn't mean that the caller isalso built-in or not. Namely, when only the sound core is built-in(CONFIG_SND=y) while the driver is a module (CONFIG_SND_USB_AUDIO=m),the passed module pointer is ignored even if it's non-NULL, andcard->module remains as NULL. This would result in the missing modulereference up/down at the device open/close, leading to a race with thecode execution after the module removal.For addressing the bug, move the assignment of card->module again outof ifdef. The WARN_ON() is still wrapped with ifdef because themodule can be really NULL when all sound drivers are built-in.Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it wouldlead to a false-positive NULL module check. Admittedly it won't catchperfectly, i.e. no check is performed when CONFIG_SND=y. But, it's noreal problem as it's only for debugging, and the condition is prettyrare.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38608 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix netif state handlingmlx5e_suspend cleans resources only if netif_device_present() returnstrue. However, mlx5e_resume changes the state of netif, viamlx5e_nic_enable, only if reg_state == NETREG_REGISTERED.In the below case, the above leads to NULL-ptr Oops[1] and memoryleaks:mlx5e_probe _mlx5e_resume mlx5e_attach_netdev mlx5e_nic_enable <-- netdev not reg, not calling netif_device_attach() register_netdev <-- failed for some reason.ERROR_FLOW: _mlx5e_suspend <-- netif_device_present return false, resources aren't freed :(Hence, clean resources in this case as well.[1]BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 0 P4D 0Oops: 0010 [#1] SMPCPU: 2 PID: 9345 Comm: test-ovs-ct-gen Not tainted 6.5.0_for_upstream_min_debug_2023_09_05_16_01 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:0x0Code: Unable to access opcode bytes at0xffffffffffffffd6.RSP: 0018:ffff888178aaf758 EFLAGS: 00010246Call Trace: ? __die+0x20/0x60 ? page_fault_oops+0x14c/0x3c0 ? exc_page_fault+0x75/0x140 ? asm_exc_page_fault+0x22/0x30 notifier_call_chain+0x35/0xb0 blocking_notifier_call_chain+0x3d/0x60 mlx5_blocking_notifier_call_chain+0x22/0x30 [mlx5_core] mlx5_core_uplink_netdev_event_replay+0x3e/0x60 [mlx5_core] mlx5_mdev_netdev_track+0x53/0x60 [mlx5_ib] mlx5_ib_roce_init+0xc3/0x340 [mlx5_ib] __mlx5_ib_add+0x34/0xd0 [mlx5_ib] mlx5r_probe+0xe1/0x210 [mlx5_ib] ? auxiliary_match_id+0x6a/0x90 auxiliary_bus_probe+0x38/0x80 ? driver_sysfs_add+0x51/0x80 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 bus_probe_device+0x86/0xa0 device_add+0x637/0x840 __auxiliary_device_add+0x3b/0xa0 add_adev+0xc9/0x140 [mlx5_core] mlx5_rescan_drivers_locked+0x22a/0x310 [mlx5_core] mlx5_register_device+0x53/0xa0 [mlx5_core] mlx5_init_one_devl_locked+0x5c4/0x9c0 [mlx5_core] mlx5_init_one+0x3b/0x60 [mlx5_core] probe_one+0x44c/0x730 [mlx5_core] local_pci_probe+0x3e/0x90 pci_device_probe+0xbf/0x210 ? kernfs_create_link+0x5d/0xa0 ? sysfs_do_create_link_sd+0x60/0xc0 really_probe+0xc9/0x3e0 ? driver_probe_device+0x90/0x90 __driver_probe_device+0x80/0x160 driver_probe_device+0x1e/0x90 __device_attach_driver+0x7d/0x100 bus_for_each_drv+0x80/0xd0 __device_attach+0xbc/0x1f0 pci_bus_add_device+0x54/0x80 pci_iov_add_virtfn+0x2e6/0x320 sriov_enable+0x208/0x420 mlx5_core_sriov_configure+0x9e/0x200 [mlx5_core] sriov_numvfs_store+0xae/0x1a0 kernfs_fop_write_iter+0x10c/0x1a0 vfs_write+0x291/0x3c0 ksys_write+0x5f/0xe0 do_syscall_64+0x3d/0x90 entry_SYSCALL_64_after_hwframe+0x46/0xb0 CR2: 0000000000000000 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38615 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn't be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn'tpresent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38662 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don't intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39471 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: add error handle to avoid out-of-boundsif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process shouldbe stop to avoid out-of-bounds read, so directly return -EINVAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40934 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:HID: logitech-dj: Fix memory leak in logi_dj_recv_switch_to_dj_mode()Fix a memory leak on logi_dj_recv_send_report() error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40978 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix crash while reading debugfs attributeThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directlyon a __user pointer, which results into the crash.To fix this issue, use a small local stack buffer for sprintf() and thencall simple_read_from_buffer(), which in turns make the copy_to_user()call.BUG: unable to handle page fault for address: 00007f4801111000PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0Oops: 0002 [#1] PREEMPT SMP PTIHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023RIP: 0010:memcpy_orig+0xcd/0x130RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000fRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fffR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7afFS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f4800f20b4d

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41002 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/sec - Fix memory leak for sec resource releaseThe AIV is one of the SEC resources. When releasing resources,it need to release the AIV resources at the same time.Otherwise, memory leakage occurs.The aiv resource release is added to the sec resource releasefunction.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41006 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:netrom: Fix a memory leak in nr_heartbeat_expiry()syzbot reported a memory leak in nr_create() [0].Commit 409db27e3a2e ("netrom: Fix use-after-free of a listening socket.")added sock_hold() to the nr_heartbeat_expiry() function, wherea) a socket has a SOCK_DESTROY flag orb) a listening socket has a SOCK_DEAD flag.But in the case "a," when the SOCK_DESTROY flag is set, the file descriptorhas already been closed and the nr_release() function has been called.So it makes no sense to hold the reference count because no one willcall another nr_destroy_socket() and put it as in the case "b."nr_connect nr_establish_data_link nr_start_heartbeatnr_release switch (nr->state) case NR_STATE_3 nr->state = NR_STATE_2 sock_set_flag(sk, SOCK_DESTROY); nr_rx_frame nr_process_rx_frame switch (nr->state) case NR_STATE_2 nr_state2_machine() nr_disconnect() nr_sk(sk)->state = NR_STATE_0 sock_set_flag(sk, SOCK_DEAD) nr_heartbeat_expiry switch (nr->state) case NR_STATE_0 if (sock_flag(sk, SOCK_DESTROY) || (sk->sk_state == TCP_LISTEN && sock_flag(sk, SOCK_DEAD))) sock_hold() // ( !!! ) nr_destroy_socket()To fix the memory leak, let's call sock_hold() only for a listening socket.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller.[0]: https://syzkaller.appspot.com/bug?extid=d327a1f3b12e1e206c16

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41023 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix task_struct reference leakDuring the execution of the following stress test with linux-rt:stress-ng --cyclic 30 --timeout 30 --minimize --quietkmemleak frequently reported a memory leak concerning the task_struct:unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 .@.............. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] dup_task_struct+0x30/0x540 [<00000000c5ca0f0b>] copy_process+0x3d9/0x50e0 [<00000000ced59777>] kernel_clone+0xb0/0x770 [<00000000a50befdc>] __do_sys_clone+0xb6/0xf0 [<000000001dbf2008>] do_syscall_64+0x5d/0xf0 [<00000000552900ff>] entry_SYSCALL_64_after_hwframe+0x6e/0x76The issue occurs in start_dl_timer(), which increments the task_structreference count and sets a timer. The timer callback, dl_task_timer,is supposed to decrement the reference count upon expiration. However,if enqueue_task_dl() is called before the timer expires and cancels it,the reference count is not decremented, leading to the leak.This patch fixes the reference leak by ensuring the task_structreference count is properly decremented when the timer is canceled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41039 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: cs_dsp: Fix overflow checking of wmfw headerFix the checking that firmware file buffer is large enough for thewmfw header, to prevent overrunning the buffer.The original code tested that the firmware data buffer containedenough bytes for the sums of the size of the structs wmfw_header + wmfw_adsp1_sizes + wmfw_footerBut wmfw_adsp1_sizes is only used on ADSP1 firmware. For ADSP2 andHalo Core the equivalent struct is wmfw_adsp2_sizes, which is4 bytes longer. So the length check didn't guarantee that thereare enough bytes in the firmware buffer for a header withwmfw_adsp2_sizes.This patch splits the length check into three separate parts. Eachof the wmfw_header, wmfw_adsp?_sizes and wmfw_footer are checkedseparately before they are used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41042 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prefer nft_chain_validatenft_chain_validate already performs loop detection because a cycle willresult in a call stack overflow (ctx->level >= NFT_JUMP_STACK_SIZE).It also follows maps via ->validate callback in nft_lookup, so thereappears no reason to iterate the maps again.nf_tables_check_loops() and all its helper functions can be removed.This improves ruleset load time significantly, from 23s down to 12s.This also fixes a crash bug. Old loop detection code can result inunbounded recursion:BUG: TASK stack guard page was hit at ....Oops: stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1[..]with a suitable ruleset during validation of register stores.I can't see any actual reason to attempt to check for this fromnft_validate_register_store(), at this point the transaction is still inprogress, so we don't have a full picture of the rule graph.For nf-next it might make sense to either remove it or make this dependon table->validate_state in case we could catch an error earlier(for improved error reporting to userspace).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41065 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Whitelist dtl slub object for copying to userspaceReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled asshown below. kernel BUG at mm/usercopy.c:102! Oops: Exception in kernel mode, sig: 5 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85 Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries NIP: c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8 REGS: c000000120c078c0 TRAP: 0700 Not tainted (6.10.0-rc3) MSR: 8000000000029033 CR: 2828220f XER: 0000000e CFAR: c0000000001fdc80 IRQMASK: 0 [ ... GPRs omitted ... ] NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0 LR [c0000000005d23d0] usercopy_abort+0x74/0xb0 Call Trace: usercopy_abort+0x74/0xb0 (unreliable) __check_heap_object+0xf8/0x120 check_heap_object+0x218/0x240 __check_object_size+0x84/0x1a4 dtl_file_read+0x17c/0x2c4 full_proxy_read+0x8c/0x110 vfs_read+0xdc/0x3a0 ksys_read+0x84/0x144 system_call_exception+0x124/0x330 system_call_vectored_common+0x15c/0x2ec --- interrupt: 3000 at 0x7fff81f3ab34Commit 6d07d1cd300f ("usercopy: Restrict non-usercopy caches to size 0")requires that only whitelisted areas in slab/slub objects can be copied touserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.Dtl contains hypervisor dispatch events which are expected to be read byprivileged users. Hence mark this safe for user access.Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist theentire object.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45306 Severity: Moderate CVSS3 score: 4.4

Description: Vim is an open source, command line text editor. Patch v9.1.0038 optimized how the cursor position is calculated and removed a loop, that verified that the cursor position always points inside a line and does not become invalid by pointing beyond the end ofa line. Back then we assumed this loop is unnecessary. However, this change made it possible that the cursor position stays invalid and points beyond the end of a line, which would eventually cause a heap-buffer-overflow when trying to access the line pointer atthe specified cursor position. It's not quite clear yet, what can lead to this situation that the cursor points to an invalid position. That's why patch v9.1.0707 does not include a test case. The only observed impact has been a program crash. This issue has been addressed in with the patch v9.1.0707. All users are advised to upgrade.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2024-46702 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:thunderbolt: Mark XDomain as unplugged when router is removedI noticed that when we do discrete host router NVM upgrade and it getshot-removed from the PCIe side as a result of NVM firmware authentication,if there is another host connected with enabled paths we hang in tearingthem down. This is due to fact that the Thunderbolt networking driveralso tries to cleanup the paths and ends up blocking intb_disconnect_xdomain_paths() waiting for the domain lock.However, at this point we already cleaned the paths in tb_stop() sothere is really no need for tb_disconnect_xdomain_paths() to do thatanymore. Furthermore it already checks if the XDomain is unplugged andbails out early so take advantage of that and mark the XDomain asunplugged when we remove the parent router.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46754 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Remove tst_run from lwt_seg6local_prog_ops.The syzbot reported that the lwt_seg6 related BPF ops can be invokedvia bpf_test_run() without without entering input_action_end_bpf()first.Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCALprobably didn't work since it was introduced in commit 04d4b274e2a("ipv6: sr: Add seg6local action End.BPF"). The reason is that theper-CPU variable seg6_bpf_srh_states::srh is never assigned in the selftest case but each BPF function expects it.Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47794 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Prevent tailcall infinite loop caused by freplaceThere is a potential infinite loop issue that can occur when using acombination of tail calls and freplace.In an upcoming selftest, the attach target for entry_freplace oftailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call inentry_freplace leads to entry_tc. This results in an infinite loop:entry_tc -> subprog_tc -> entry_freplace --tailcall-> entry_tc.The problem arises because the tail_call_cnt in entry_freplace resets tozero each time entry_freplace is executed, causing the tail call mechanismto never terminate, eventually leading to a kernel panic.To fix this issue, the solution is twofold:1. Prevent updating a program extended by an freplace program to a prog_array map.2. Prevent extending a program that is already part of a prog_array map with an freplace program.This ensures that:* If a program or its subprogram has been extended by an freplace program, it can no longer be updated to a prog_array map.* If a program has been added to a prog_array map, neither it nor its subprograms can be extended by an freplace program.Moreover, an extension program should not be tailcalled. As such, return-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to aprog_array map.Additionally, fix a minor code style issue by replacing eight spaces with atab for proper formatting.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49569 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-rdma: unquiesce admin_q before destroy itKernel will hang on destroy admin_q while we create ctrl failed, suchas following calltrace:PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] __schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blk_mq_freeze_queue_wait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blk_freeze_queue at ffffffff82a4113a #4 [ff61d23de260fc90] blk_cleanup_queue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvme_rdma_destroy_admin_queue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvme_rdma_setup_ctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvme_rdma_create_ctrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmf_dev_write at ffffffffc024f362 #9 [ff61d23de260fe38] vfs_write at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIG_RAX: 0000000000000001 CS: 0033 SS: 002bThis due to we have quiesced admi_q before cancel requests, but forgotto unquiesce before destroy it, as a result we fail to drain thepending requests, and hang on blk_mq_freeze_queue_wait() forever. Heretry to reuse nvme_rdma_teardown_admin_queue() to fix this issue andsimplify the code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49968 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: filesystems without casefold feature cannot be mounted with siphashWhen mounting the ext4 filesystem, if the default hash version is set toDX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50117 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd: Guard against bad data for ATIF ACPI methodIf a BIOS provides bad data in response to an ATIF method callthis causes a NULL pointer dereference in the caller.```? show_regs (arch/x86/kernel/dumpstack.c:478 (discriminator 1))? __die (arch/x86/kernel/dumpstack.c:423 arch/x86/kernel/dumpstack.c:434)? page_fault_oops (arch/x86/mm/fault.c:544 (discriminator 2) arch/x86/mm/fault.c:705 (discriminator 2))? do_user_addr_fault (arch/x86/mm/fault.c:440 (discriminator 1) arch/x86/mm/fault.c:1232 (discriminator 1))? acpi_ut_update_object_reference (drivers/acpi/acpica/utdelete.c:642)? exc_page_fault (arch/x86/mm/fault.c:1542)? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623)? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:387 (discriminator 2)) amdgpu? amdgpu_atif_query_backlight_caps.constprop.0 (drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c:386 (discriminator 1)) amdgpu```It has been encountered on at least one system, so guard for it.(cherry picked from commit c9b7c809b89f24e9372a4e7f02d64c950b07fdee)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50153 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: core: Fix null-ptr-deref in target_alloc_device()There is a null-ptr-deref issue reported by KASAN:BUG: KASAN: null-ptr-deref in target_alloc_device+0xbc4/0xbe0 [target_core_mod]... kasan_report+0xb9/0xf0 target_alloc_device+0xbc4/0xbe0 [target_core_mod] core_dev_setup_virtual_lun0+0xef/0x1f0 [target_core_mod] target_core_init_configfs+0x205/0x420 [target_core_mod] do_one_initcall+0xdd/0x4e0... entry_SYSCALL_64_after_hwframe+0x76/0x7eIn target_alloc_device(), if allocing memory for dev queues fails, thendev will be freed by dev->transport->free_device(), but dev->transportis not initialized at that time, which will lead to a null pointerreference problem.Fixing this bug by freeing dev with hba->backend->ops->free_device().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50162 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: devmap: provide rxq after redirectrxq contains a pointer to the device from wherethe redirect happened. Currently, the BPF programthat was executed after a redirect via BPF_MAP_TYPE_DEVMAP*does not have it set.This is particularly bad since accessing ingress_ifindex, e.g.SEC("xdp")int prog(struct xdp_md *pkt){ return bpf_redirect_map(&dev_redirect_map, 0, 0);}SEC("xdp/devmap")int prog_after_redirect(struct xdp_md *pkt){ bpf_printk("ifindex %i", pkt->ingress_ifindex); return XDP_PASS;}depends on access to rxq, so a NULL pointer gets dereferenced:<1>[ 574.475170] BUG: kernel NULL pointer dereference, address: 0000000000000000<1>[ 574.475188] #PF: supervisor read access in kernel mode<1>[ 574.475194] #PF: error_code(0x0000) - not-present page<6>[ 574.475199] PGD 0 P4D 0<4>[ 574.475207] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI<4>[ 574.475217] CPU: 4 UID: 0 PID: 217 Comm: kworker/4:1 Not tainted 6.11.0-rc5-reduced-00859-g780801200300 #23<4>[ 574.475226] Hardware name: Intel(R) Client Systems NUC13ANHi7/NUC13ANBi7, BIOS ANRPL357.0026.2023.0314.1458 03/14/2023<4>[ 574.475231] Workqueue: mld mld_ifc_work<4>[ 574.475247] RIP: 0010:bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475257] Code: cc cc cc cc cc cc cc 80 00 00 00 cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 57 20 <48> 8b 52 00 8b 92 e0 00 00 00 48 bf f8 a6 d5 c4 5d a0 ff ff be 0b<4>[ 574.475263] RSP: 0018:ffffa62440280c98 EFLAGS: 00010206<4>[ 574.475269] RAX: ffffa62440280cd8 RBX: 0000000000000001 RCX: 0000000000000000<4>[ 574.475274] RDX: 0000000000000000 RSI: ffffa62440549048 RDI: ffffa62440280ce0<4>[ 574.475278] RBP: ffffa62440280c98 R08: 0000000000000002 R09: 0000000000000001<4>[ 574.475281] R10: ffffa05dc8b98000 R11: ffffa05f577fca40 R12: ffffa05dcab24000<4>[ 574.475285] R13: ffffa62440280ce0 R14: ffffa62440549048 R15: ffffa62440549000<4>[ 574.475289] FS: 0000000000000000(0000) GS:ffffa05f4f700000(0000) knlGS:0000000000000000<4>[ 574.475294] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<4>[ 574.475298] CR2: 0000000000000000 CR3: 000000025522e000 CR4: 0000000000f50ef0<4>[ 574.475303] PKRU: 55555554<4>[ 574.475306] Call Trace:<4>[ 574.475313] <4>[ 574.475318] ? __die+0x23/0x70<4>[ 574.475329] ? page_fault_oops+0x180/0x4c0<4>[ 574.475339] ? skb_pp_cow_data+0x34c/0x490<4>[ 574.475346] ? kmem_cache_free+0x257/0x280<4>[ 574.475357] ? exc_page_fault+0x67/0x150<4>[ 574.475368] ? asm_exc_page_fault+0x26/0x30<4>[ 574.475381] ? bpf_prog_5e13354d9cf5018a_prog_after_redirect+0x17/0x3c<4>[ 574.475386] bq_xmit_all+0x158/0x420<4>[ 574.475397] __dev_flush+0x30/0x90<4>[ 574.475407] veth_poll+0x216/0x250 [veth]<4>[ 574.475421] __napi_poll+0x28/0x1c0<4>[ 574.475430] net_rx_action+0x32d/0x3a0<4>[ 574.475441] handle_softirqs+0xcb/0x2c0<4>[ 574.475451] do_softirq+0x40/0x60<4>[ 574.475458] <4>[ 574.475461] <4>[ 574.475464] __local_bh_enable_ip+0x66/0x70<4>[ 574.475471] __dev_queue_xmit+0x268/0xe40<4>[ 574.475480] ? selinux_ip_postroute+0x213/0x420<4>[ 574.475491] ? alloc_skb_with_frags+0x4a/0x1d0<4>[ 574.475502] ip6_finish_output2+0x2be/0x640<4>[ 574.475512] ? nf_hook_slow+0x42/0xf0<4>[ 574.475521] ip6_finish_output+0x194/0x300<4>[ 574.475529] ? __pfx_ip6_finish_output+0x10/0x10<4>[ 574.475538] mld_sendpack+0x17c/0x240<4>[ 574.475548] mld_ifc_work+0x192/0x410<4>[ 574.475557] process_one_work+0x15d/0x380<4>[ 574.475566] worker_thread+0x29d/0x3a0<4>[ 574.475573] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475580] ? __pfx_worker_thread+0x10/0x10<4>[ 574.475587] kthread+0xcd/0x100<4>[ 574.475597] ? __pfx_kthread+0x10/0x10<4>[ 574.475606] ret_from_fork+0x31/0x50<4>[ 574.475615] ? __pfx_kthread+0x10/0x10<4>[ 574.475623] ret_from_fork_asm+0x1a/0x---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56574 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: ts2020: fix null-ptr-deref in ts2020_probe()KASAN reported a null-ptr-deref issue when executing the followingcommand: # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020] RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809 RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010 RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6 R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790 R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001 FS: 00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ts2020_probe+0xad/0xe10 [ts2020] i2c_device_probe+0x421/0xb40 really_probe+0x266/0x850 ...The cause of the problem is that when using sysfs to dynamically registeran i2c device, there is no platform data, but the probe process of ts2020needs to use platform data, resulting in a null pointer being accessed.Solve this problem by adding checks to platform data.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56588 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Create all dump files during debugfs initializationFor the current debugfs of hisi_sas, after user triggers dump, thedriver allocate memory space to save the register information and createdebugfs files to display the saved information. In this process, thedebugfs files created after each dump.Therefore, when the dump is triggered while the driver is unbind, thefollowing hang occurs:[67840.853907] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0[67840.862947] Mem abort info:[67840.865855] ESR = 0x0000000096000004[67840.869713] EC = 0x25: DABT (current EL), IL = 32 bits[67840.875125] SET = 0, FnV = 0[67840.878291] EA = 0, S1PTW = 0[67840.881545] FSC = 0x04: level 0 translation fault[67840.886528] Data abort info:[67840.889524] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000[67840.895117] CM = 0, WnR = 0, TnD = 0, TagAccess = 0[67840.900284] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[67840.905709] user pgtable: 4k pages, 48-bit VAs, pgdp=0000002803a1f000[67840.912263] [00000000000000a0] pgd=0000000000000000, p4d=0000000000000000[67840.919177] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP[67840.996435] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)[67841.003628] pc : down_write+0x30/0x98[67841.007546] lr : start_creating.part.0+0x60/0x198[67841.012495] sp : ffff8000b979ba20[67841.016046] x29: ffff8000b979ba20 x28: 0000000000000010 x27: 0000000000024b40[67841.023412] x26: 0000000000000012 x25: ffff20202b355ae8 x24: ffff20202b35a8c8[67841.030779] x23: ffffa36877928208 x22: ffffa368b4972240 x21: ffff8000b979bb18[67841.038147] x20: ffff00281dc1e3c0 x19: fffffffffffffffe x18: 0000000000000020[67841.045515] x17: 0000000000000000 x16: ffffa368b128a530 x15: ffffffffffffffff[67841.052888] x14: ffff8000b979bc18 x13: ffffffffffffffff x12: ffff8000b979bb18[67841.060263] x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa368b1289b18[67841.067640] x8 : 0000000000000012 x7 : 0000000000000000 x6 : 00000000000003a9[67841.075014] x5 : 0000000000000000 x4 : ffff002818c5cb00 x3 : 0000000000000001[67841.082388] x2 : 0000000000000000 x1 : ffff002818c5cb00 x0 : 00000000000000a0[67841.089759] Call trace:[67841.092456] down_write+0x30/0x98[67841.096017] start_creating.part.0+0x60/0x198[67841.100613] debugfs_create_dir+0x48/0x1f8[67841.104950] debugfs_create_files_v3_hw+0x88/0x348 [hisi_sas_v3_hw][67841.111447] debugfs_snapshot_regs_v3_hw+0x708/0x798 [hisi_sas_v3_hw][67841.118111] debugfs_trigger_dump_v3_hw_write+0x9c/0x120 [hisi_sas_v3_hw][67841.125115] full_proxy_write+0x68/0xc8[67841.129175] vfs_write+0xd8/0x3f0[67841.132708] ksys_write+0x70/0x108[67841.136317] __arm64_sys_write+0x24/0x38[67841.140440] invoke_syscall+0x50/0x128[67841.144385] el0_svc_common.constprop.0+0xc8/0xf0[67841.149273] do_el0_svc+0x24/0x38[67841.152773] el0_svc+0x38/0xd8[67841.156009] el0t_64_sync_handler+0xc0/0xc8[67841.160361] el0t_64_sync+0x1a4/0x1a8[67841.164189] Code: b9000882 d2800002 d2800023 f9800011 (c85ffc05)[67841.170443] ---[ end trace 0000000000000000 ]---To fix this issue, create all directories and files during debugfsinitialization. In this way, the driver only needs to allocate memoryspace to save information each time the user triggers dumping.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56599 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: avoid NULL pointer error during sdio removeWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdioworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ONis set to yes, kernel panic will happen:Call trace: destroy_workqueue+0x1c/0x258 ath10k_sdio_remove+0x84/0x94 sdio_bus_remove+0x50/0x16c device_release_driver_internal+0x188/0x25c device_driver_detach+0x20/0x2cThis is because during 'rmmod ath10k', ath10k_sdio_remove() will callath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()will finally be called in ath10k_core_destroy(). This function will freestruct cfg80211_registered_device *rdev and all its members, includingwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdioworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.After device release, destroy_workqueue() will use NULL pointer then thekernel panic happen.Call trace:ath10k_sdio_remove ->ath10k_core_unregister ...... ->ath10k_core_stop ->ath10k_hif_stop ->ath10k_sdio_irq_disable ->ath10k_hif_power_down ->del_timer_sync(&ar_sdio->sleep_timer) ->ath10k_core_destroy ->ath10k_mac_destroy ->ieee80211_free_hw ->wiphy_free ...... ->wiphy_dev_release ->destroy_workqueueNeed to call destroy_workqueue() before ath10k_core_destroy(), freethe work queue buffer first and then free pointer of work queue byath10k_core_destroy(). This order matches the error path order inath10k_sdio_probe().No work will be queued on sdio workqueue between it is destroyed andath10k_core_destroy() is called. Based on the call_stack above, thereason is:Only ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() andath10k_sdio_irq_disable() will queue work on sdio workqueue.Sleep timer will be deleted before ath10k_core_destroy() inath10k_hif_power_down().ath10k_sdio_irq_disable() only be called in ath10k_hif_stop().ath10k_core_unregister() will call ath10k_hif_power_down() to stop hifbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.Tested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57883 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: independent PMD page table shared countThe folio refcount may be increased unexpectly through try_get_folio() bycaller such as split_huge_pages. In huge_pmd_unshare(), we use refcountto check whether a pmd page table is shared. The check is incorrect ifthe refcount is increased by the above caller, and this can cause the pagetable leaked: BUG: Bad page state in process sh pfn:109324 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324 flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff) page_type: f2(table) raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000 raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000 page dumped because: nonzero mapcount ... CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G B 6.13.0-rc2master+ #7 Tainted: [B]=BAD_PAGE Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: show_stack+0x20/0x38 (C) dump_stack_lvl+0x80/0xf8 dump_stack+0x18/0x28 bad_page+0x8c/0x130 free_page_is_bad_report+0xa4/0xb0 free_unref_page+0x3cc/0x620 __folio_put+0xf4/0x158 split_huge_pages_all+0x1e0/0x3e8 split_huge_pages_write+0x25c/0x2d8 full_proxy_write+0x64/0xd8 vfs_write+0xcc/0x280 ksys_write+0x70/0x110 __arm64_sys_write+0x24/0x38 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x34/0x128 el0t_64_sync_handler+0xc8/0xd0 el0t_64_sync+0x190/0x198The issue may be triggered by damon, offline_page, page_idle, etc, whichwill increase the refcount of page table.1. The page table itself will be discarded after reporting the "nonzero mapcount".2. The HugeTLB page mapped by the page table miss freeing since we treat the page table as shared and a shared page table will not be unmapped.Fix it by introducing independent PMD page table shared count. Asdescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390gmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscvpmds, so we can reuse the field as pt_share_count.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21957 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla1280: Fix kernel oops when debug level > 2A null dereference or oops exception will eventually occur when qla1280.cdriver is compiled with DEBUG_QLA1280 enabled and ql_debug_level > 2. Ithink its clear from the code that the intention here is sg_dma_len(s) notlength of sg_next(s) when printing the debug info.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22057 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: decrease cached dst counters in dst_releaseUpstream fix ac888d58869b ("net: do not delay dst_entries_add() indst_release()") moved decrementing the dst count from dst_destroy todst_release to avoid accessing already freed data in case of netnsdismantle. However in case CONFIG_DST_CACHE is enabled and OvS+tunnelsare used, this fix is incomplete as the same issue will be seen forcached dsts: Unable to handle kernel paging request at virtual address ffff5aabf6b5c000 Call trace: percpu_counter_add_batch+0x3c/0x160 (P) dst_release+0xec/0x108 dst_cache_destroy+0x68/0xd8 dst_destroy+0x13c/0x168 dst_destroy_rcu+0x1c/0xb0 rcu_do_batch+0x18c/0x7d0 rcu_core+0x174/0x378 rcu_core_si+0x18/0x30Fix this by invalidating the cache, and thus decrementing cached dstcounters, in dst_release too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22870 Severity: Moderate CVSS3 score: 4.4

Description: Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID as a hostname component. For example, when the NO_PROXY environment variable is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly match and not be proxied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
containerd > 0-0 (version in image is 1.7.27-150000.123.1).

CVE-2025-37740 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: add sanity check for agwidth in dbMountThe width in dmapctl of the AG is zero, it trigger a divide error whencalculating the control page level in dbAllocAG.To avoid this issue, add a check for agwidth in dbAllocAG.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37883 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Add check for get_zeroed_page()Add check for the return value of get_zeroed_page() insclp_console_init() to prevent null pointer dereference.Furthermore, to solve the memory leak caused by the loopallocation, add a free helper to do the free job.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37923 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix oob write in trace_seq_to_buffer()syzbot reported this bug:==================================================================BUG: KASAN: slab-out-of-bounds in trace_seq_to_buffer kernel/trace/trace.c:1830 [inline]BUG: KASAN: slab-out-of-bounds in tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822Write of size 4507 at addr ffff888032b6b000 by task syz.2.320/7260CPU: 1 UID: 0 PID: 7260 Comm: syz.2.320 Not tainted 6.15.0-rc1-syzkaller-00301-g3bde70a2c827 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:408 [inline] print_report+0xc3/0x670 mm/kasan/report.c:521 kasan_report+0xe0/0x110 mm/kasan/report.c:634 check_region_inline mm/kasan/generic.c:183 [inline] kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189 __asan_memcpy+0x3c/0x60 mm/kasan/shadow.c:106 trace_seq_to_buffer kernel/trace/trace.c:1830 [inline] tracing_splice_read_pipe+0x6be/0xdd0 kernel/trace/trace.c:6822 ....==================================================================It has been reported that trace_seq_to_buffer() tries to copy more datathan PAGE_SIZE to buf. Therefore, to prevent this, we should use thesmaller of trace_seq_used(&iter->seq) and PAGE_SIZE as an argument.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37927 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/amd: Fix potential buffer overflow in parse_ivrs_acpihidThere is a string parsing logic error which can lead to an overflow of hidor uid buffers. Comparing ACPIID_LEN against a total string length doesn'ttake into account the lengths of individual hid and uid buffers so thecheck is insufficient in some cases. For example if the length of hidstring is 4 and the length of the uid string is 260, the length of strwill be equal to ACPIID_LEN + 1 but uid string will overflow uid bufferwhich size is 256.The same applies to the hid string with length 13 and uid string withlength 250.Check the length of hid and uid strings separately to preventbuffer overflow.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37994 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: displayport: Fix NULL pointer accessThis patch ensures that the UCSI driver waits for all pending tasks in theucsi_displayport_work workqueue to finish executing before proceeding withthe partner removal.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38034 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: correct the order of prelim_ref arguments in btrfs__prelim_refbtrfs_prelim_ref() calls the old and new reference variables in theincorrect order. This causes a NULL pointer dereference because oldrefis passed as NULL to trace_btrfs_prelim_ref_insert().Note, trace_btrfs_prelim_ref_insert() is being called with newref asoldref (and oldref as NULL) on purpose in order to print outthe values of newref.To reproduce:echo 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enablePerform some writeback operations.Backtrace:BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary) 7ca2cef72d5e9c600f0c7718adb6462de8149622 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014 RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130 Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88 RSP: 0018:ffffce44820077a0 EFLAGS: 00010286 RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010 RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010 R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000 R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540 FS: 00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0 PKRU: 55555554 Call Trace: prelim_ref_insert+0x1c1/0x270 find_parent_nodes+0x12a6/0x1ee0 ? __entry_text_end+0x101f06/0x101f09 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 ? srso_alias_return_thunk+0x5/0xfbef5 btrfs_is_data_extent_shared+0x167/0x640 ? fiemap_process_hole+0xd0/0x2c0 extent_fiemap+0xa5c/0xbc0 ? __entry_text_end+0x101f05/0x101f09 btrfs_fiemap+0x7e/0xd0 do_vfs_ioctl+0x425/0x9d0 __x64_sys_ioctl+0x75/0xc0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38042 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma-glue: Drop skip_fdq argument from k3_udma_glue_reset_rx_chnThe user of k3_udma_glue_reset_rx_chn() e.g. ti_am65_cpsw_nuss canrun on multiple platforms having different DMA architectures.On some platforms there can be one FDQ for all flows in the RX channelwhile for others there is a separate FDQ for each flow in the RX channel.So far we have been relying on the skip_fdq argument ofk3_udma_glue_reset_rx_chn().Instead of relying on the user to provide this information, infer itbased on DMA architecture during k3_udma_glue_request_rx_chn() and save itin an internal flag 'single_fdq'. Use that flag atk3_udma_glue_reset_rx_chn() to deicide if the FDQ needsto be cleared for every flow or just for flow 0.Fixes the below issue on ti_am65_cpsw_nuss driver on AM62-SK.> ip link set eth1 down> ip link set eth0 down> ethtool -L eth0 rx 8> ip link set eth0 up> modprobe -r ti_am65_cpsw_nuss[ 103.045726] ------------[ cut here ]------------[ 103.050505] k3_knav_desc_pool size 512000 != avail 64000[ 103.050703] WARNING: CPU: 1 PID: 450 at drivers/net/ethernet/ti/k3-cppi-desc-pool.c:33 k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.068810] Modules linked in: ti_am65_cpsw_nuss(-) k3_cppi_desc_pool snd_soc_hdmi_codec crct10dif_ce snd_soc_simple_card snd_soc_simple_card_utils display_connector rtc_ti_k3 k3_j72xx_bandgap tidss drm_client_lib snd_soc_davinci_mcasp drm_dma_helper tps6598x phylink snd_soc_ti_udma rti_wdt drm_display_helper snd_soc_tlv320aic3x_i2c typec at24 phy_gmii_sel snd_soc_ti_edma snd_soc_tlv320aic3x sii902x snd_soc_ti_sdma sa2ul omap_mailbox drm_kms_helper authenc cfg80211 rfkill fuse drm drm_panel_orientation_quirks backlight ip_tables x_tables ipv6 [last unloaded: k3_cppi_desc_pool][ 103.119950] CPU: 1 UID: 0 PID: 450 Comm: modprobe Not tainted 6.13.0-rc7-00001-g9c5e3435fa66 #1011[ 103.119968] Hardware name: Texas Instruments AM625 SK (DT)[ 103.119974] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)[ 103.119983] pc : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.148007] lr : k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool][ 103.154709] sp : ffff8000826ebbc0[ 103.158015] x29: ffff8000826ebbc0 x28: ffff0000090b6300 x27: 0000000000000000[ 103.165145] x26: 0000000000000000 x25: 0000000000000000 x24: ffff0000019df6b0[ 103.172271] x23: ffff0000019df6b8 x22: ffff0000019df410 x21: ffff8000826ebc88[ 103.179397] x20: 000000000007d000 x19: ffff00000a3b3000 x18: 0000000000000000[ 103.186522] x17: 0000000000000000 x16: 0000000000000000 x15: 000001e8c35e1cde[ 103.193647] x14: 0000000000000396 x13: 000000000000035c x12: 0000000000000000[ 103.200772] x11: 000000000000003a x10: 00000000000009c0 x9 : ffff8000826eba20[ 103.207897] x8 : ffff0000090b6d20 x7 : ffff00007728c180 x6 : ffff00007728c100[ 103.215022] x5 : 0000000000000001 x4 : ffff000000508a50 x3 : ffff7ffff6146000[ 103.222147] x2 : 0000000000000000 x1 : e300b4173ee6b200 x0 : 0000000000000000[ 103.229274] Call trace:[ 103.231714] k3_cppi_desc_pool_destroy+0xa0/0xa8 [k3_cppi_desc_pool] (P)[ 103.238408] am65_cpsw_nuss_free_rx_chns+0x28/0x4c [ti_am65_cpsw_nuss][ 103.244942] devm_action_release+0x14/0x20[ 103.249040] release_nodes+0x3c/0x68[ 103.252610] devres_release_all+0x8c/0xdc[ 103.256614] device_unbind_cleanup+0x18/0x60[ 103.260876] device_release_driver_internal+0xf8/0x178[ 103.266004] driver_detach+0x50/0x9c[ 103.269571] bus_remove_driver+0x6c/0xbc[ 103.273485] driver_unregister+0x30/0x60[ 103.277401] platform_driver_unregister+0x14/0x20[ 103.282096] am65_cpsw_nuss_driver_exit+0x18/0xff4 [ti_am65_cpsw_nuss][ 103.288620] __arm64_sys_delete_module+0x17c/0x25c[ 103.293404] invoke_syscall+0x44/0x100[ 103.297149] el0_svc_common.constprop.0+0xc0/0xe0[ 103.301845] do_el0_svc+0x1c/0x28[ 103.305155] el0_svc+0x28/0x98---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38100 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:x86/iopl: Cure TIF_IO_BITMAP inconsistenciesio_bitmap_exit() is invoked from exit_thread() when a task exists orwhen a fork fails. In the latter case the exit_thread() cleans upresources which were allocated during fork().io_bitmap_exit() invokes task_update_io_bitmap(), which in turn ends upin tss_update_io_bitmap(). tss_update_io_bitmap() operates on thecurrent task. If current has TIF_IO_BITMAP set, but no bitmap installed,tss_update_io_bitmap() crashes with a NULL pointer dereference.There are two issues, which lead to that problem: 1) io_bitmap_exit() should not invoke task_update_io_bitmap() when the task, which is cleaned up, is not the current task. That's a clear indicator for a cleanup after a failed fork(). 2) A task should not have TIF_IO_BITMAP set and neither a bitmap installed nor IOPL emulation level 3 activated. This happens when a kernel thread is created in the context of a user space thread, which has TIF_IO_BITMAP set as the thread flags are copied and the IO bitmap pointer is cleared. Other than in the failed fork() case this has no impact because kernel threads including IO workers never return to user space and therefore never invoke tss_update_io_bitmap().Cure this by adding the missing cleanups and checks: 1) Prevent io_bitmap_exit() to invoke task_update_io_bitmap() if the to be cleaned up task is not the current task. 2) Clear TIF_IO_BITMAP in copy_thread() unconditionally. For user space forks it is set later, when the IO bitmap is inherited in io_bitmap_share().For paranoia sake, add a warning into tss_update_io_bitmap() to catchthe case, when that code is invoked with inconsistent state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38135 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:serial: Fix potential null-ptr-deref in mlb_usio_probe()devm_ioremap() can return NULL on error. Currently, mlb_usio_probe()does not check for this case, which could result in a NULL pointerdereference.Add NULL check after devm_ioremap() to prevent this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38152 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: core: Clear table_sz when rproc_shutdownThere is case as below could trigger kernel dump:Use U-Boot to start remote processor(rproc) with resource tablepublished to a fixed address by rproc. After Kernel boots up,stop the rproc, load a new firmware which doesn't have resource table,and start rproc.When starting rproc with a firmware not have resource table,`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` willtrigger dump, because rproc->cache_table is set to NULL during the laststop operation, but rproc->table_sz is still valid.This issue is found on i.MX8MP and i.MX9.Dump as below:Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation faultData abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0user pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000[0000000000000000] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 0000000096000004 [#1] PREEMPT SMPModules linked in:CPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38Hardware name: NXP i.MX8MPlus EVK board (DT)pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __pi_memcpy_generic+0x110/0x22clr : rproc_start+0x88/0x1e0Call trace: __pi_memcpy_generic+0x110/0x22c (P) rproc_boot+0x198/0x57c state_store+0x40/0x104 dev_attr_store+0x18/0x2c sysfs_kf_write+0x7c/0x94 kernfs_fop_write_iter+0x120/0x1cc vfs_write+0x240/0x378 ksys_write+0x70/0x108 __arm64_sys_write+0x1c/0x28 invoke_syscall+0x48/0x10c el0_svc_common.constprop.0+0xc0/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x30/0xcc el0t_64_sync_handler+0x10c/0x138 el0t_64_sync+0x198/0x19cClear rproc->table_sz to address the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38215 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_varIf fb_add_videomode() in do_register_framebuffer() fails to allocatememory for fb_videomode, it will later lead to a null-ptr dereference infb_videomode_to_var(), as the fb_info is registered while not having themode in modelist that is expected to be there, i.e. the one that isdescribed in fb_info->var.================================================================general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 1 PID: 30371 Comm: syz-executor.1 Not tainted 5.10.226-syzkaller #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014RIP: 0010:fb_videomode_to_var+0x24/0x610 drivers/video/fbdev/core/modedb.c:901Call Trace: display_to_var+0x3a/0x7c0 drivers/video/fbdev/core/fbcon.c:929 fbcon_resize+0x3e2/0x8f0 drivers/video/fbdev/core/fbcon.c:2071 resize_screen drivers/tty/vt/vt.c:1176 [inline] vc_do_resize+0x53a/0x1170 drivers/tty/vt/vt.c:1263 fbcon_modechanged+0x3ac/0x6e0 drivers/video/fbdev/core/fbcon.c:2720 fbcon_update_vcs+0x43/0x60 drivers/video/fbdev/core/fbcon.c:2776 do_fb_ioctl+0x6d2/0x740 drivers/video/fbdev/core/fbmem.c:1128 fb_ioctl+0xe7/0x150 drivers/video/fbdev/core/fbmem.c:1203 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:739 do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x67/0xd1================================================================Even though fbcon_init() checks beforehand if fb_match_mode() invar_to_display() fails, it can not prevent the panic because fbcon_init()does not return error code. Considering this and the comment in the codeabout fb_match_mode() returning NULL - "This should not happen" - it isbetter to prevent registering the fb_info if its mode was not setsuccessfully. Also move fb_add_videomode() closer to the beginning ofdo_register_framebuffer() to avoid having to do the cleanup on fail.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38229 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:media: cxusb: no longer judge rbuf when the write failssyzbot reported a uninit-value in cxusb_i2c_xfer. [1]Only when the write operation of usb_bulk_msg() in dvb_usb_generic_rw()succeeds and rlen is greater than 0, the read operation of usb_bulk_msg()will be executed to read rlen bytes of data from the dvb device into therbuf.In this case, although rlen is 1, the write operation failed which resultedin the dvb read operation not being executed, and ultimately variable i wasnot initialized.[1]BUG: KMSAN: uninit-value in cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline]BUG: KMSAN: uninit-value in cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 cxusb_gpio_tuner drivers/media/usb/dvb-usb/cxusb.c:124 [inline] cxusb_i2c_xfer+0x153a/0x1a60 drivers/media/usb/dvb-usb/cxusb.c:196 __i2c_transfer+0xe25/0x3150 drivers/i2c/i2c-core-base.c:-1 i2c_transfer+0x317/0x4a0 drivers/i2c/i2c-core-base.c:2315 i2c_transfer_buffer_flags+0x125/0x1e0 drivers/i2c/i2c-core-base.c:2343 i2c_master_send include/linux/i2c.h:109 [inline] i2cdev_write+0x210/0x280 drivers/i2c/i2c-dev.c:183 do_loop_readv_writev fs/read_write.c:848 [inline] vfs_writev+0x963/0x14e0 fs/read_write.c:1057 do_writev+0x247/0x5c0 fs/read_write.c:1101 __do_sys_writev fs/read_write.c:1169 [inline] __se_sys_writev fs/read_write.c:1166 [inline] __x64_sys_writev+0x98/0xe0 fs/read_write.c:1166 x64_sys_call+0x2229/0x3c80 arch/x86/include/generated/asm/syscalls_64.h:21 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x1e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38312 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It'sthen passed to fb_cvt_hperiod(), where it's used as a divider -- divisionby 0 will result in kernel oops. Add a sanity check for cvt.f_refresh toavoid such overflow...Found by Linux Verification Center (linuxtesting.org) with the Svace staticanalysis tool.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38342 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:software node: Correct a OOB check in software_node_get_reference_args()software_node_get_reference_args() wants to get @index-th element, sothe property value requires at least '(index + 1) * sizeof(*ref)' bytesbut that can not be guaranteed by current OOB check, and may cause OOBfor malformed property.Fix by using as OOB check '((index + 1) * sizeof(*ref) > prop->length)'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38345 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ACPICA: fix acpi operand cache leak in dswstate.cACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732I found an ACPI cache leak in ACPI early termination and boot continuing case.When early termination occurs due to malicious ACPI table, Linux kernelterminates ACPI function and continues to boot process. While kernel terminatesACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.Boot log of ACPI operand cache leak is as follows:>[ 0.585957] ACPI: Added _OSI(Module Device)>[ 0.587218] ACPI: Added _OSI(Processor Device)>[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)>[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device)>[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)>[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)>[ 0.597858] ACPI: Unable to start the ACPI Interpreter>[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)>[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects>[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26>[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006>[ 0.609177] Call Trace:>[ 0.610063] ? dump_stack+0x5c/0x81>[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0>[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27>[ 0.613906] ? acpi_os_delete_cache+0xa/0x10>[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b>[ 0.619293] ? acpi_terminate+0xa/0x14>[ 0.620394] ? acpi_init+0x2af/0x34f>[ 0.621616] ? __class_create+0x4c/0x80>[ 0.623412] ? video_setup+0x7f/0x7f>[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27>[ 0.625861] ? do_one_initcall+0x4e/0x1a0>[ 0.627513] ? kernel_init_freeable+0x19e/0x21f>[ 0.628972] ? rest_init+0x80/0x80>[ 0.630043] ? kernel_init+0xa/0x100>[ 0.631084] ? ret_from_fork+0x25/0x30>[ 0.633343] vgaarb: loaded>[ 0.635036] EDAC MC: Ver: 3.0.0>[ 0.638601] PCI: Probing PCI hardware>[ 0.639833] PCI host bridge to bus 0000:00>[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]> ... Continue to boot and log is omitted ...I analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_delete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()function uses walk_state->operand_index for start position of the top, butacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.Therefore, this causes acpi operand memory leak.This cache leak causes a security threat because an old kernel (<= 4.9) showsmemory locations of kernel functions in stack dump. Some malicious userscould use this information to neutralize kernel ASLR.I made a patch to fix ACPI operand cache leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38591 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject narrower access to pointer ctx fieldsThe following BPF program, simplified from a syzkaller repro, causes akernel warning: r0 = *(u8 *)(r1 + 169); exit;With pointer field sk being at offset 168 in __sk_buff. This access isdetected as a narrower read in bpf_skb_is_valid_access because itdoesn't match offsetof(struct __sk_buff, sk). It is therefore allowedand later proceeds to bpf_convert_ctx_access. Note that for the"is_narrower_load" case in the convert_ctx_accesses(), the insn->offis aligned, so the cnt may not be 0 because it matches theoffsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,the target_size stays 0 and the verifier errors with a kernel warning: verifier bug: error during ctx access conversion(1)This patch fixes that to return a proper "invalid bpf_context accessoff=X size=Y" error on the load instruction.The same issue affects multiple other fields in context structures thatallow narrow access. Some other non-affected fields (for sk_msg,sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr forconsistency.Note this syzkaller crash was reported in the "Closes" link below, whichused to be about a different bug, fixed incommit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructionsin insn_def_regno()"). Because syzbot somehow confused the two bugs,the new crash and repro didn't get reported to the mailing list.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38692 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: add cluster chain loop check for dirAn infinite loop may occur if the following conditions occur due tofile system corruption.(1) Condition for exfat_count_dir_entries() to loop infinitely. - The cluster chain includes a loop. - There is no UNUSED entry in the cluster chain.(2) Condition for exfat_create_upcase_table() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and up-case table entry in the cluster chain of the root directory.(3) Condition for exfat_load_bitmap() to loop infinitely. - The cluster chain of the root directory includes a loop. - There are no UNUSED entry and bitmap entry in the cluster chain of the root directory.(4) Condition for exfat_find_dir_entry() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation.(5) Condition for exfat_check_dir_empty() to loop infinitely. - The cluster chain includes a loop. - The unused directory entries were exhausted by some operation. - All files and sub-directories under the directory are deleted.This commit adds checks to break the above infinite loop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39706 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Destroy KFD debugfs after destroy KFD wqSince KFD proc content was moved to kernel debugfs, we can't destroy KFDdebugfs before kfd_process_destroy_wq. Move kfd_process_destroy_wq priorto kfd_debugfs_fini to fix a kernel NULL pointer problem. It happenswhen /sys/kernel/debug/kfd was already destroyed in kfd_debugfs_fini butkfd_process_destroy_wq calls kfd_debugfs_remove_process. This line debugfs_remove_recursive(entry->proc_dentry);tries to remove /sys/kernel/debug/kfd/proc/ while/sys/kernel/debug/kfd is already gone. It hangs the kernel by kernelNULL pointer.(cherry picked from commit 0333052d90683d88531558dcfdbf2525cc37c233)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39738 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: do not allow relocation of partially dropped subvolumes[BUG]There is an internal report that balance triggered transaction abort,with the following call trace: item 85 key (594509824 169 0) itemoff 12599 itemsize 33 extent refs 1 gen 197740 flags 2 ref#0: tree block backref root 7 item 86 key (594558976 169 0) itemoff 12566 itemsize 33 extent refs 1 gen 197522 flags 2 ref#0: tree block backref root 7 ... BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0 BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117 ------------[ cut here ]------------ BTRFS: Transaction aborted (error -117) WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]And btrfs check doesn't report anything wrong related to the extenttree.[CAUSE]The cause is a little complex, firstly the extent tree indeed doesn'thave the backref for 594526208.The extent tree only have the following two backrefs around that bytenron-disk: item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33 refs 1 gen 197740 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREE item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33 refs 1 gen 197522 flags TREE_BLOCK tree block skinny level 0 (176 0x7) tree block backref root CSUM_TREEBut the such missing backref item is not an corruption on disk, as theoffending delayed ref belongs to subvolume 934, and that subvolume isbeing dropped: item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439 generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328 last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0 drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2 level 2 generation_v2 198229And that offending tree block 594526208 is inside the dropped range ofthat subvolume. That explains why there is no backref item for thatbytenr and why btrfs check is not reporting anything wrong.But this also shows another problem, as btrfs will do all the orphansubvolume cleanup at a read-write mount.So half-dropped subvolume should not exist after an RW mount, andbalance itself is also exclusive to subvolume cleanup, meaning weshouldn't hit a subvolume half-dropped during relocation.The root cause is, there is no orphan item for this subvolume.In fact there are 5 subvolumes from around 2021 that have the sameproblem.It looks like the original report has some older kernels running, andcaused those zombie subvolumes.Thankfully upstream commit 8d488a8c7ba2 ("btrfs: fix subvolume/snapshotdeletion not triggered on mount") has long fixed the bug.[ENHANCEMENT]For repairing such old fs, btrfs-progs will be enhanced.Considering how delayed the problem will show up (at run delayed reftime) and at that time we have to abort transaction already, it is toolate.Instead here we reject any half-dropped subvolume for reloc tree at theearliest time, preventing confusion and extra time wasted on debuggingsimilar bugs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39763 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: APEI: send SIGBUS to current task if synchronous memory error not recoveredIf a synchronous error is detected as a result of user-space processtriggering a 2-bit uncorrected error, the CPU will take a synchronouserror exception such as Synchronous External Abort (SEA) on Arm64. Thekernel will queue a memory_failure() work which poisons the relatedpage, unmaps the page, and then sends a SIGBUS to the process, so thata system wide panic can be avoided.However, no memory_failure() work will be queued when abnormalsynchronous errors occur. These errors can include situations likeinvalid PA, unexpected severity, no memory failure config support,invalid GUID section, etc. In such a case, the user-space process willtrigger SEA again. This loop can potentially exceed the platformfirmware threshold or even trigger a kernel hard lockup, leading to asystem reboot.Fix it by performing a force kill if no memory_failure() work is queuedfor synchronous errors.[ rjw: Changelog edits ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39787 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:soc: qcom: mdt_loader: Ensure we don't read past the ELF headerWhen the MDT loader is used in remoteproc, the ELF header is sanitizedbeforehand, but that's not necessary the case for other clients.Validate the size of the firmware buffer to ensure that we don't readpast the end as we iterate over the header. e_phentsize and e_shentsizeare validated as well, to ensure that the assumptions about step size inthe traversal are valid.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39958 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommu/s390: Make attach succeed when the device was surprise removedWhen a PCI device is removed with surprise hotplug, there may still beattempts to attach the device to the default domain as part of tear downvia (__iommu_release_dma_ownership()), or because the removal happensduring probe (__iommu_probe_device()). In both cases zpci_register_ioat()fails with a cc value indicating that the device handle is invalid. Thisis because the device is no longer part of the instance as far as thehypervisor is concerned.Currently this leads to an error return and s390_iommu_attach_device()fails. This triggers the WARN_ON() in __iommu_group_set_domain_nofail()because attaching to the default domain must never fail.With the device fenced by the hypervisor no DMAs to or from memory arepossible and the IOMMU translations have no effect. Proceed as if theregistration was successful and let the hotplug event handling clean upthe device.This is similar to how devices in the error state are handled sincecommit 59bbf596791b ("iommu/s390: Make attach succeed even if the deviceis in error state") except that for removal the domain will not beregistered later. This approach was also previously discussed at thelink.Handle both cases, error state and removal, in a helper which checks ifthe error needs to be propagated or ignored. Avoid magic numbercondition codes by using the pre-existing, but never used, defines forPCI load/store condition codes and rename them to reflect that theyapply to all PCI instructions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39980 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:nexthop: Forbid FDB status change while nexthop is in a groupThe kernel forbids the creation of non-FDB nexthop groups with FDBnexthops: # ip nexthop add id 1 via 192.0.2.1 fdb # ip nexthop add id 2 group 1 Error: Non FDB nexthop group cannot have fdb nexthops.And vice versa: # ip nexthop add id 3 via 192.0.2.2 dev dummy1 # ip nexthop add id 4 group 3 fdb Error: FDB nexthop group can only have fdb nexthops.However, as long as no routes are pointing to a non-FDB nexthop group,the kernel allows changing the type of a nexthop from FDB to non-FDB andvice versa: # ip nexthop add id 5 via 192.0.2.2 dev dummy1 # ip nexthop add id 6 group 5 # ip nexthop replace id 5 via 192.0.2.2 fdb # echo $? 0This configuration is invalid and can result in a NPD [1] since FDBnexthops are not associated with a nexthop device: # ip route add 198.51.100.1/32 nhid 6 # ping 198.51.100.1Fix by preventing nexthop FDB status change while the nexthop is in agroup: # ip nexthop add id 7 via 192.0.2.2 dev dummy1 # ip nexthop add id 8 group 7 # ip nexthop replace id 7 via 192.0.2.2 fdb Error: Cannot change nexthop FDB status while in a group.[1]BUG: kernel NULL pointer dereference, address: 00000000000003c0[...]Oops: Oops: 0000 [#1] SMPCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014RIP: 0010:fib_lookup_good_nhc+0x1e/0x80[...]Call Trace: fib_table_lookup+0x541/0x650 ip_route_output_key_hash_rcu+0x2ea/0x970 ip_route_output_key_hash+0x55/0x80 __ip4_datagram_connect+0x250/0x330 udp_connect+0x2b/0x60 __sys_connect+0x9c/0xd0 __x64_sys_connect+0x18/0x20 do_syscall_64+0xa4/0x2a0 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40021 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: dynevent: Add a missing lockdown check on dyneventSince dynamic_events interface on tracefs is compatible withkprobe_events and uprobe_events, it should also check the lockdownstatus and reject if it is set.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40032 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Add NULL check for DMA channels before releaseThe fields dma_chan_tx and dma_chan_rx of the struct pci_epf_test can beNULL even after EPF initialization. Then it is prudent to check thatthey have non-NULL values before releasing the channels. Add the checksin pci_epf_test_clean_dma_chan().Without the checks, NULL pointer dereferences happen and they can leadto a kernel panic in some cases: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000050 Call trace: dma_release_channel+0x2c/0x120 (P) pci_epf_test_epc_deinit+0x94/0xc0 [pci_epf_test] pci_epc_deinit_notify+0x74/0xc0 tegra_pcie_ep_pex_rst_irq+0x250/0x5d8 irq_thread_fn+0x34/0xb8 irq_thread+0x18c/0x2e8 kthread+0x14c/0x210 ret_from_fork+0x10/0x20[mani: trimmed the stack trace]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40144 Severity: Moderate CVSS3 score: 4.4

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40178 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:pid: Add a judgment for ns null in pid_nr_ns__task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) {Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : __task_pid_nr_ns+0x74/0xd0 lr : __task_pid_nr_ns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: __task_pid_nr_ns+0x74/0xd0 ... __handle_irq_event_percpu+0xd4/0x284 handle_irq_event+0x48/0xb0 handle_fasteoi_irq+0x160/0x2d8 generic_handle_domain_irq+0x44/0x60 gic_handle_irq+0x4c/0x114 call_on_irq_stack+0x3c/0x74 do_interrupt_handler+0x4c/0x84 el1_interrupt+0x34/0x58 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x68/0x6c account_kernel_stack+0x60/0x144 exit_task_stack_account+0x1c/0x80 do_exit+0x7e4/0xaf8 ... get_signal+0x7bc/0x8d8 do_notify_resume+0x128/0x828 el0_svc+0x6c/0x70 el0t_64_sync_handler+0x68/0xbc el0t_64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40279 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: act_connmark: initialize struct tc_ife to fix kernel leakIn tcf_connmark_dump(), the variable 'opt' was partially initialized using adesignatied initializer. While the padding bytes are reamineduninitialized. nla_put() copies the entire structure into anetlink message, these uninitialized bytes leaked to userspace.Initialize the structure with memset before assigning its fieldsto ensure all members and padding are cleared prior to beign copied.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68286 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check NULL before accessing[WHAT]IGT kms_cursor_legacy's long-nonblocking-modeset-vs-cursor-atomicfails with NULL pointer dereference. This can be reproduced withboth an eDP panel and a DP monitors connected. BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 13 UID: 0 PID: 2960 Comm: kms_cursor_lega Not tainted6.16.0-99-custom #8 PREEMPT(voluntary) Hardware name: AMD ........ RIP: 0010:dc_stream_get_scanoutpos+0x34/0x130 [amdgpu] Code: 57 4d 89 c7 41 56 49 89 ce 41 55 49 89 d5 41 54 49 89 fc 53 48 83 ec 18 48 8b 87 a0 64 00 00 48 89 75 d0 48 c7 c6 e0 41 30 c2 <48> 8b 38 48 8b 9f 68 06 00 00 e8 8d d7 fd ff 31 c0 48 81 c3 e0 02 RSP: 0018:ffffd0f3c2bd7608 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffd0f3c2bd7668 RDX: ffffd0f3c2bd7664 RSI: ffffffffc23041e0 RDI: ffff8b32494b8000 RBP: ffffd0f3c2bd7648 R08: ffffd0f3c2bd766c R09: ffffd0f3c2bd7760 R10: ffffd0f3c2bd7820 R11: 0000000000000000 R12: ffff8b32494b8000 R13: ffffd0f3c2bd7664 R14: ffffd0f3c2bd7668 R15: ffffd0f3c2bd766c FS: 000071f631b68700(0000) GS:ffff8b399f114000(0000)knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000001b8105000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: dm_crtc_get_scanoutpos+0xd7/0x180 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x86/0x1c0 [amdgpu] ? __pfx_amdgpu_crtc_get_scanout_position+0x10/0x10[amdgpu] amdgpu_crtc_get_scanout_position+0x27/0x50 [amdgpu] drm_crtc_vblank_helper_get_vblank_timestamp_internal+0xf7/0x400 drm_crtc_vblank_helper_get_vblank_timestamp+0x1c/0x30 drm_crtc_get_last_vbltimestamp+0x55/0x90 drm_crtc_next_vblank_start+0x45/0xa0 drm_atomic_helper_wait_for_fences+0x81/0x1f0 ...(cherry picked from commit 621e55f1919640acab25383362b96e65f2baea3c)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-68764 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Automounted filesystems should inherit ro,noexec,nodev,sync flagsWhen a filesystem is being automounted, it needs to preserve theuser-set superblock mount options, such as the "ro" flag.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-69277 Severity: Moderate CVSS3 score: 4.4

Description: libsodium before ad3004e, in atypical use cases involving certain custom cryptography or untrusted data to crypto_core_ed25519_is_valid_point, mishandles checks for whether an elliptic curve point is valid because it sometimes allows points that aren't in the main cryptographic group.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libsodium23 > 0-0 (version in image is 1.0.18-150000.4.8.1).

CVE-2025-71091 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:team: fix check for port enabled in team_queue_override_port_prio_changed()There has been a syzkaller bug reported recently with the followingtrace:list_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)------------[ cut here ]------------kernel BUG at lib/list_debug.c:59!Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTICPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014RIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59Code: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ffRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286RAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000RDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005RBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000R10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230R13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480FS: 00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0Call Trace: __list_del_entry_valid include/linux/list.h:132 [inline] __list_del_entry include/linux/list.h:223 [inline] list_del_rcu include/linux/rculist.h:178 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline] __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline] team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline] team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534 team_option_set drivers/net/team/team_core.c:376 [inline] team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653 genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg net/socket.c:742 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684 __sys_sendmsg+0x16d/0x220 net/socket.c:2716 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fThe problem is in this flow:1) Port is enabled, queue_id != 0, in qom_list2) Port gets disabled -> team_port_disable() -> team_queue_override_port_del() -> del (removed from list)3) Port is disabled, queue_id != 0, not in any list4) Priority changes -> team_queue_override_port_prio_changed() -> checks: port disabled && queue_id != 0 -> calls del - hits the BUG as it is removed alreadyTo fix this, change the check in team_queue_override_port_prio_changed()so it returns early if port is not enabled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2020-13632 Severity: Moderate CVSS3 score: 4.3

Description: ext/fts3/fts3_snippet.c in SQLite before 3.32.0 has a NULL pointer dereference via a crafted matchinfo() query.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2020-9327 Severity: Moderate CVSS3 score: 4.3

Description: In SQLite 3.31.1, isAuxiliaryVtabOperator allows attackers to trigger a NULL pointer dereference and segmentation fault because of generated column optimizations.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2024-26715 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspendIn current scenario if Plug-out and Plug-In performed continuouslythere could be a chance while checking for dwc->gadget_driver indwc3_gadget_suspend, a NULL pointer dereference may occur.Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadgetCPU1 basically clears the variable and CPU2 checks the variable.Consider CPU1 is running and right before gadget_driver is clearedand in parallel CPU2 executes dwc3_gadget_suspend where it findsdwc->gadget_driver which is not NULL and resumes execution and thenCPU1 completes execution. CPU2 executes dwc3_disconnect_gadget whereit checks dwc->gadget_driver is already NULL because of which theNULL pointer deference occur.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26747 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: roles: fix NULL pointer issue when put module's referenceIn current design, usb role class driver will get usb_role_switch parent'smodule reference after the user get usb_role_switch device and put thereference after the user put the usb_role_switch device. However, theparent device of usb_role_switch may be removed before the user put theusb_role_switch. If so, then, NULL pointer issue will be met when the userput the parent module's reference.This will save the module pointer in structure of usb_role_switch. Then,we don't need to find module by iterating long relations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26836 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:platform/x86: think-lmi: Fix password opcode ordering for workstationsThe Lenovo workstations require the password opcode to be run beforethe attribute value is changed (if Admin password is enabled).Tested on some Thinkpads to confirm they are OK with this order too.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27024 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/rds: fix WARNING in rds_conn_connect_if_downIf connection isn't established yet, get_mr() will fail, trigger connection afterget_mr().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46676 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Add poll mod list filling checkIn case of im_protocols value is 1 and tm_protocols value is 0 thiscombination successfully passes the check'if (!im_protocols && !tm_protocols)' in the nfc_start_poll().But then after pn533_poll_create_mod_list() call in pn533_start_poll()poll mod list will remain empty and dev->poll_mod_count will remain 0which lead to division by zero.Normally no im protocol has value 1 in the mask, so this combination isnot expected by driver. But these protocol values actually come fromuserspace via Netlink interface (NFC_CMD_START_POLL operation). So abroken or malicious program may pass a message containing a "bad"combination of protocol parameter values so that dev->poll_mod_countis not incremented inside pn533_poll_create_mod_list(), thus leadingto division by zero.Call trace looks like:nfc_genl_start_poll() nfc_start_poll() ->start_poll() pn533_start_poll()Add poll mod list filling check.Found by Linux Verification Center (linuxtesting.org) with SVACE.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50269 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: musb: sunxi: Fix accessing an released usb phyCommit 6ed05c68cbca ("usb: musb: sunxi: Explicitly release USB PHY onexit") will cause that usb phy @glue->xceiv is accessed after released.1) register platform driver @sunxi_musb_driver// get the usb phy @glue->xceivsunxi_musb_probe() -> devm_usb_get_phy().2) register and unregister platform driver @musb_drivermusb_probe() -> sunxi_musb_init()use the phy here//the phy is released heremusb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy()3) register @musb_driver againmusb_probe() -> sunxi_musb_init()use the phy here but the phy has been released at 2)....Fixed by reverting the commit, namely, removing devm_usb_put_phy()from sunxi_musb_exit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-10158 Severity: Moderate CVSS3 score: 4.3

Description: A malicious client acting as the receiver of an rsync file transfer can trigger an out of bounds read of a heap based buffer, via a negative array index. The malicious rsync client requires at least read access to the remote rsync module in order to trigger the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
rsync > 0-0 (version in image is 3.2.3-150400.3.23.3).

CVE-2025-12084 Severity: Moderate CVSS3 score: 4.3

Description: When building nested elements using xml.dom.minidom methods such as appendChild() that have a dependency on _clear_id_cache() the algorithm is quadratic. Availability can be impacted when building excessively nested documents.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2026-21441 Severity: Moderate CVSS3 score: 4.3

Description: urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311-urllib3 > 0-0 (version in image is 2.0.7-150400.7.21.1).

CVE-2021-37577 Severity: Moderate CVSS3 score: 4.2

Description: Bluetooth LE and BR/EDR Secure Connections pairing and Secure Simple Pairing using the Passkey entry protocol in Bluetooth Core Specifications 2.1 through 5.3 may permit an unauthenticated man-in-the-middle attacker to identify the Passkey used during pairing by reflection of a crafted public key with the same X coordinate as the offered public key and by reflection of the authentication evidence of the initiating device, potentially permitting this attacker to complete authenticated pairing with the responding device using the correct Passkey for the pairing session. This is a related issue to CVE-2020-26558.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49197 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:af_netlink: Fix shift out of bounds in group mask calculationWhen a netlink message is received, netlink_recvmsg() fills in the addressof the sender. One of the fields is the 32-bit bitfield nl_groups, whichcarries the multicast group on which the message was received. The leastsignificant bit corresponds to group 1, and therefore the highest groupthat the field can represent is 32. Above that, the UB sanitizer flags theout-of-bounds shift attempts.Which bits end up being set in such case is implementation defined, butit's either going to be a wrong non-zero value, or zero, which is at leastnot misleading. Make the latter choice deterministic by always setting to 0for higher-numbered multicast groups.To get information about membership in groups >= 32, userspace is expectedto use nl_pktinfo control messages[0], which are enabled by NETLINK_PKTINFOsocket option.[0] https://lwn.net/Articles/147608/The way to trigger this issue is e.g. through monitoring the BRVLAN group: # bridge monitor vlan & # ip link add name br type bridgeWhich produces the following citation: UBSAN: shift-out-of-bounds in net/netlink/af_netlink.c:162:19 shift exponent 32 is too large for 32-bit type 'int'

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50366 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:powercap: intel_rapl: fix UBSAN shift-out-of-bounds issueWhen value < time_unit, the parameter of ilog2() will be zero andthe return value is -1. u64(-1) is too large for shift exponentand then will trigger shift-out-of-bounds:shift exponent 18446744073709551615 is too large for 32-bit type 'int'Call Trace: rapl_compute_time_window_core rapl_write_data_raw set_time_window store_constraint_time_window_us

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-40550 Severity: Moderate CVSS3 score: 4.2

Description: An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system's boot phase.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
shim > 0-0 (version in image is 15.8-150300.4.23.1).

CVE-2024-49878 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:resource: fix region_intersects() vs add_memory_driver_managed()On a system with CXL memory, the resource tree (/proc/iomem) related toCXL memory may look like something as follows.490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem)Because drivers/dax/kmem.c calls add_memory_driver_managed() duringonlining CXL memory, which makes "System RAM (kmem)" a descendant of "CXLWindow X". This confuses region_intersects(), which expects all "SystemRAM" resources to be at the top level of iomem_resource. This can lead tobugs.For example, when the following command line is executed to write somememory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/sthe command fails as expected. However, the error code is wrong. Itshould be "Operation not permitted" instead of "Bad address". Moreseriously, the /dev/mem permission checking in devmem_is_allowed() passesincorrectly. Although the accessing is prevented later because ioremap()isn't allowed to map system RAM, it is a potential security issue. Duringcommand executing, the following warning is reported in the kernel log forcalling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53The details of command execution process are as follows. In the aboveresource tree, "System RAM" is a descendant of "CXL Window 0" instead of atop level resource. So, region_intersects() will report no System RAMresources in the CXL memory region incorrectly, because it only checks thetop level resources. Consequently, devmem_is_allowed() will return 1(allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject theaccess.So, region_intersects() needs to be fixed to work correctly with theresource tree with "System RAM" not at top level as above. To fix it, ifwe found a unmatched resource in the top level, we will continue to searchmatched resources in its descendant resources. So, we will not miss anymatched resources in resource tree anymore.In the new implementation, an example resource tree|------------- "CXL Window 0" ------------||-- "System RAM" --|will behave similar as the following fake resource tree forregion_intersects(, IORESOURCE_SYSTEM_RAM, ),|-- "System RAM" --||-- "CXL Window 0a" --|Where "CXL Window 0a" is part of the original "CXL Window 0" thatisn't covered by "System RAM".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49934 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.nameIt's observed that a crash occurs during hot-remove a memory device,in which user is accessing the hugetlb. See calltrace as following:------------[ cut here ]------------WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc smirror dm_region_hash dm_log dm_modCPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:do_user_addr_fault+0x2a0/0x790Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200<...snip...>BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440<...snip...>? dentry_name+0x2fa/0x440vsnprintf+0x1f3/0x4f0vprintk_store+0x23a/0x540vprintk_emit+0x6d/0x330_printk+0x58/0x80dump_mapping+0x10b/0x1a0? __pfx_free_object_rcu+0x10/0x10__dump_page+0x26b/0x3e0? vprintk_emit+0xe0/0x330? _printk+0x58/0x80? dump_page+0x17/0x50dump_page+0x17/0x50do_migrate_range+0x2f7/0x7f0? do_migrate_range+0x42/0x7f0? offline_pages+0x2f4/0x8c0offline_pages+0x60a/0x8c0memory_subsys_offline+0x9f/0x1c0? lockdep_hardirqs_on+0x77/0x100? _raw_spin_unlock_irqrestore+0x38/0x60device_offline+0xe3/0x110state_store+0x6e/0xc0kernfs_fop_write_iter+0x143/0x200vfs_write+0x39f/0x560ksys_write+0x65/0xf0do_syscall_64+0x62/0x130Previously, some sanity check have been done in dump_mapping() beforethe print facility parsing '%pd' though, it's still possible to run intoan invalid dentry.d_name.name.Since dump_mapping() only needs to dump the filename only, retrieve itby itself in a safer way to prevent an unnecessary crash.Note that either retrieving the filename with '%pd' orstrncpy_from_kernel_nofault(), the filename could be unreliable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-8006 Severity: Moderate CVSS3 score: 4.2

Description: Remote packet capture support is disabled by default in libpcap. When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex(). One of the function arguments can be a filesystem path, which normally means a directory with input data files. When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).

CVE-2025-22079 Severity: Moderate CVSS3 score: 4.2

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: validate l_tree_depth to avoid out-of-bounds accessThe l_tree_depth field is 16-bit (__le16), but the actual maximum depth islimited to OCFS2_MAX_PATH_DEPTH.Add a check to prevent out-of-bounds access if l_tree_depth has an invalidvalue, which may occur when reading from a corrupted mounted disk [1].

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22134 Severity: Moderate CVSS3 score: 4.2

Description: When switching to other buffers using the :all command and visual mode still being active, this may cause a heap-buffer overflow, because Vim does not properly end visual mode and therefore may try to access beyond the end of a line in a buffer. In Patch 9.1.1003 Vim will correctly reset the visual mode before opening other windows and buffers and therefore fix this bug. In addition it does verify that it won't try to access a position if the position is greater than the corresponding buffer line. Impact is medium since the user must have switched on visual mode when executing the :all ex command. The Vim project would like to thank github user gandalf4a for reporting this issue. The issue has been fixed as of Vim patch v9.1.1003

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-24014 Severity: Moderate CVSS3 score: 4.2

Description: Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2022-49124 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/mce: Work around an erratum on fast string copy instructionsA rare kernel panic scenario can happen when the following conditionsare met due to an erratum on fast string copy instructions:1) An uncorrected error.2) That error must be in first cache line of a page.3) Kernel must execute page_copy from the page immediately before thatpage.The fast string copy instructions ("REP; MOVS*") could consume anuncorrectable memory error in the cache line _right after_ the desiredregion to copy and raise an MCE.Bit 0 of MSR_IA32_MISC_ENABLE can be cleared to disable fast stringcopy and will avoid such spurious machine checks. However, that is lesspreferable due to the permanent performance impact. Considering memorypoison is rare, it's desirable to keep fast string copy enabled until anMCE is seen.Intel has confirmed the following:1. The CPU erratum of fast string copy only applies to Skylake,Cascade Lake and Cooper Lake generations.Directly return from the MCE handler:2. Will result in complete execution of the "REP; MOVS*" with no dataloss or corruption.3. Will not result in another MCE firing on the next poisoned cache linedue to "REP; MOVS*".4. Will resume execution from a correct point in code.5. Will result in the same instruction that triggered the MCE firing asecond MCE immediately for any other software recoverable data fetcherrors.6. Is not safe without disabling the fast string copy, as the next faststring copy of the same buffer on the same CPU would result in a PANICMCE.This should mitigate the erratum completely with the only caveat thatthe fast string copy is disabled on the affected hyper thread thusperformance degradation.This is still better than the OS crashing on MCEs raised on anirrelevant process due to "REP; MOVS*' accesses in a kernel context,e.g., copy_page.Injected errors on 1st cache line of 8 anonymous pages of process'proc1' and observed MCE consumption from 'proc2' with no panic(directly returned).Without the fix, the host panicked within a few minutes on arandom 'proc2' process due to kernel access from copy_page. [ bp: Fix comment style + touch ups, zap an unlikely(), improve the quirk function's readability. ]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49531 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:loop: implement ->free_diskEnsure that the lo_device which is stored in the gendisk privatedata is valid until the gendisk is freed. Currently the loop driveruses a lot of effort to make sure a device is not freed when it isstill in use, but to to fix a potential deadlock this will be relaxeda bit soon.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50405 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/tunnel: wait until all sk_user_data reader finish before releasing the sockThere is a race condition in vxlan that when deleting a vxlan deviceduring receiving packets, there is a possibility that the sock isreleased after getting vxlan_sock vs from sk_user_data. Then inlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will gotNULL pointer dereference. e.g. #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757 #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48 #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542 #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62 [exception RIP: vxlan_ecn_decapsulate+0x3b] RIP: ffffffffc1014e7b RSP: ffffa25ec6978cb0 RFLAGS: 00010246 RAX: 0000000000000008 RBX: ffff8aa000888000 RCX: 0000000000000000 RDX: 000000000000000e RSI: ffff8a9fc7ab803e RDI: ffff8a9fd1168700 RBP: ffff8a9fc7ab803e R8: 0000000000700000 R9: 00000000000010ae R10: ffff8a9fcb748980 R11: 0000000000000000 R12: ffff8a9fd1168700 R13: ffff8aa000888000 R14: 00000000002a0000 R15: 00000000000010ae ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan] #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507 #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45 #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807 #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951 #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139 #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3 #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.shFix this by waiting for all sk_user_data reader to finish beforereleasing the sock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50579 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ftrace: fix module PLTs with mcountLi Huafei reports that mcount-based ftrace with module PLTs was brokenby commit: a6253579977e4c6f ("arm64: ftrace: consistently handle PLTs.")When a module PLTs are used and a module is loaded sufficiently far awayfrom the kernel, we'll create PLTs for any branches which areout-of-range. These are separate from the special ftrace trampolinePLTs, which the module PLT code doesn't directly manipulate.When mcount is in use this is a problem, as each mcount callsite in amodule will be initialized to point to a module PLT, but since commita6253579977e4c6f ftrace_make_nop() will assume that the callsite hasbeen initialized to point to the special ftrace trampoline PLT, andftrace_find_callable_addr() rejects other cases.This means that when ftrace tries to initialize a callsite viaftrace_make_nop(), the call to ftrace_find_callable_addr() will findthat the `_mcount` stub is out-of-range and is not handled by the ftracePLT, resulting in a splat:| ftrace_test: loading out-of-tree module taints kernel.| ftrace: no module PLT for _mcount| ------------[ ftrace bug ]------------| ftrace failed to modify| [] 0xffff800029180014| actual: 44:00:00:94| Initializing ftrace call sites| ftrace record flags: 2000000| (0)| expected tramp: ffff80000802eb3c| ------------[ cut here ]------------| WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270| Modules linked in:| CPU: 3 PID: 157 Comm: insmod Tainted: G O 6.0.0-rc6-00151-gcd722513a189-dirty #22| Hardware name: linux,dummy-virt (DT)| pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : ftrace_bug+0x94/0x270| lr : ftrace_bug+0x21c/0x270| sp : ffff80000b2bbaf0| x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000| x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00| x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8| x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff| x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118| x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666| x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030| x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4| x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001| x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022| Call trace:| ftrace_bug+0x94/0x270| ftrace_process_locs+0x308/0x430| ftrace_module_init+0x44/0x60| load_module+0x15b4/0x1ce8| __do_sys_init_module+0x1ec/0x238| __arm64_sys_init_module+0x24/0x30| invoke_syscall+0x54/0x118| el0_svc_common.constprop.4+0x84/0x100| do_el0_svc+0x3c/0xd0| el0_svc+0x1c/0x50| el0t_64_sync_handler+0x90/0xb8| el0t_64_sync+0x15c/0x160| ---[ end trace 0000000000000000 ]---| ---------test_init-----------Fix this by reverting to the old behaviour of ignoring the oldinstruction when initialising an mcount callsite in a module, which wasthe behaviour prior to commit a6253579977e4c6f.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-46839 Severity: Moderate CVSS3 score: 4.1

Description: PCI devices can make use of a functionality called phantom functions,that when enabled allows the device to generate requests using the IDsof functions that are otherwise unpopulated. This allows a device toextend the number of outstanding requests.Such phantom functions need an IOMMU context setup, but failure tosetup the context is not fatal when the device is assigned. Notfailing device assignment when such failure happens can lead to theprimary device being assigned to a guest, while some of the phantomfunctions are assigned to a different domain.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
xen-libs > 0-0 (version in image is 4.16.7_02-150400.4.72.1).

CVE-2024-23850 Severity: Moderate CVSS3 score: 4.1

Description: In btrfs_get_root_ref in fs/btrfs/disk-io.c in the Linux kernel through 6.7.1, there can be an assertion failure and crash because a subvolume can be read out too soon after its root item is inserted upon subvolume creation.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-36478 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'Writing 'power' and 'submit_queues' concurrently will trigger kernelpanic:Test script:modprobe null_blk nr_devices=0mkdir -p /sys/kernel/config/nullb/nullb0while true; do echo 1 > submit_queues; echo 4 > submit_queues; done &while true; do echo 1 > power; echo 0 > power; doneTest result:BUG: kernel NULL pointer dereference, address: 0000000000000148Oops: 0000 [#1] PREEMPT SMPRIP: 0010:__lock_acquire+0x41d/0x28f0Call Trace: lock_acquire+0x121/0x450 down_write+0x5f/0x1d0 simple_recursive_removal+0x12f/0x5c0 blk_mq_debugfs_unregister_hctxs+0x7c/0x100 blk_mq_update_nr_hw_queues+0x4a3/0x720 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk] nullb_device_submit_queues_store+0x79/0xf0 [null_blk] configfs_write_iter+0x119/0x1e0 vfs_write+0x326/0x730 ksys_write+0x74/0x150This is because del_gendisk() can concurrent withblk_mq_update_nr_hw_queues():nullb_device_power_store nullb_apply_submit_queues null_del_dev del_gendisk nullb_update_nr_hw_queues if (!dev->nullb) // still set while gendisk is deleted return 0 blk_mq_update_nr_hw_queues dev->nullb = NULLFix this problem by resuing the global mutex to protectnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38554 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issue of net_deviceThere is a reference count leak issue of the object "net_device" inax25_dev_device_down(). When the ax25 device is shutting down, theax25_dev_device_down() drops the reference count of net_device oneor zero times depending on if we goto unlock_put or not, which willcause memory leak.In order to solve the above issue, decrease the reference count ofnet_device after dev->ax25_ptr is set to null.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42155 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of protected- and secure-keysAlthough the clear-key of neither protected- nor secure-keys isaccessible, this key material should only be visible to the callingprocess. So wipe all copies of protected- or secure-keys from stack,even in case of an error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46679 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ethtool: check device is present when getting link settingsA sysfs reader can race with a device reset or removal, attempting toread device state when the device is not actually present. eg: [exception RIP: qed_get_current_link+17] #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede] #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash> struct net_device.state ffff9a9d21336000 state = 5,state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).The device is not present, note lack of __LINK_STATE_PRESENT (0b10).This is the same sort of panic as observed in commit 4224cfd7fb65("net-sysfs: add check for netdevice being present to speed_show").There are many other callers of __ethtool_get_link_ksettings() whichdon't have a device presence check.Move this check into ethtool to protect all callers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49866 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:tracing/timerlat: Fix a race during cpuhp processingThere is another found exception that the "timerlat/1" thread wasscheduled on CPU0, and lead to timer corruption finally:```ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0Modules linked in:CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014RIP: 0010:debug_print_object+0x7d/0xb0...Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ```After tracing the scheduling event, it was discovered that the migrationof the "timerlat/1" thread was performed during thread creation. Furtheranalysis confirmed that it is because the CPU online processing forosnoise is implemented through workers, which is asynchronous with theoffline processing. When the worker was scheduled to create a thread, theCPU may has already been removed from the cpu_online_mask during the offlineprocess, resulting in the inability to select the right CPU:T1 | T2[CPUHP_ONLINE] | cpu_device_down()osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock()[CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() |To fix this, skip online processing if the CPU is already offline.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53197 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox devicesA bogus device can provide a bNumConfigurations value that exceeds theinitial value used in usb_get_configuration for allocating dev->config.This can lead to out-of-bounds accesses later, e.g. inusb_destroy_configuration.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53221 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:f2fs: fix null-ptr-deref in f2fs_submit_page_bio()There's issue as follows when concurrently installing the f2fs.komodule and mounting the f2fs file system:KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]RIP: 0010:__bio_alloc+0x2fb/0x6c0 [f2fs]Call Trace: f2fs_submit_page_bio+0x126/0x8b0 [f2fs] __get_meta_page+0x1d4/0x920 [f2fs] get_checkpoint_version.constprop.0+0x2b/0x3c0 [f2fs] validate_checkpoint+0xac/0x290 [f2fs] f2fs_get_valid_checkpoint+0x207/0x950 [f2fs] f2fs_fill_super+0x1007/0x39b0 [f2fs] mount_bdev+0x183/0x250 legacy_get_tree+0xf4/0x1e0 vfs_get_tree+0x88/0x340 do_new_mount+0x283/0x5e0 path_mount+0x2b2/0x15b0 __x64_sys_mount+0x1fe/0x270 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7eAbove issue happens as the biset of the f2fs file system is notinitialized before register "f2fs_fs_type".To address above issue just register "f2fs_fs_type" at the last ininit_f2fs_fs(). Ensure that all f2fs file system resources areinitialized.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57940 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix the infinite loop in exfat_readdir()If the file system is corrupted so that a cluster is linked toitself in the cluster chain, and there is an unused directoryentry in the cluster, 'dentry' will not be incremented, causingcondition 'dentry < max_dentries' unable to prevent an infiniteloop.This infinite loop causes s_lock not to be released, and othertasks will hang, such as exfat_sync_fs().This commit stops traversing the cluster chain when there is unuseddirectory entry in the cluster to avoid this infinite loop.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22103 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix NULL pointer dereference in l3mdev_l3_rcvWhen delete l3s ipvlan: ip link del link eth0 ipvlan1 type ipvlan mode l3sThis may cause a null pointer dereference: Call trace: ip_rcv_finish+0x48/0xd0 ip_rcv+0x5c/0x100 __netif_receive_skb_one_core+0x64/0xb0 __netif_receive_skb+0x20/0x80 process_backlog+0xb4/0x204 napi_poll+0xe8/0x294 net_rx_action+0xd8/0x22c __do_softirq+0x12c/0x354This is because l3mdev_l3_rcv() visit dev->l3mdev_ops afteripvlan_l3s_unregister() assign the dev->l3mdev_ops to NULL. The processlike this: (CPU1) | (CPU2) l3mdev_l3_rcv() | check dev->priv_flags: | master = skb->dev; | | | ipvlan_l3s_unregister() | set dev->priv_flags | dev->l3mdev_ops = NULL; | visit master->l3mdev_ops |To avoid this by do not set dev->l3mdev_ops when unregister l3s ipvlan.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22113 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: avoid journaling sb update on error if journal is destroyingPresently we always BUG_ON if trying to start a transaction on a journal markedwith JBD2_UNMOUNT, since this should never happen. However, while ltp runningstress tests, it was observed that in case of some error handling paths, it ispossible for update_super_work to start a transaction after the journal isdestroyed eg:(umount)ext4_kill_sb kill_block_super generic_shutdown_super sync_filesystem /* commits all txns */ evict_inodes /* might start a new txn */ ext4_put_super flush_work(&sbi->s_sb_upd_work) /* flush the workqueue */ jbd2_journal_destroy journal_kill_thread journal->j_flags |= JBD2_UNMOUNT; jbd2_journal_commit_transaction jbd2_journal_get_descriptor_buffer jbd2_journal_bmap ext4_journal_bmap ext4_map_blocks ... ext4_inode_error ext4_handle_error schedule_work(&sbi->s_sb_upd_work) /* work queue kicks in */ update_super_work jbd2_journal_start start_this_handle BUG_ON(journal->j_flags & JBD2_UNMOUNT)Hence, introduce a new mount flag to indicate journal is destroying and only doa journaled (and deferred) update of sb if this flag is not set. Otherwise, justfallback to an un-journaled commit.Further, in the journal destroy path, we have the following sequence: 1. Set mount flag indicating journal is destroying 2. force a commit and wait for it 3. flush pending sb updatesThis sequence is important as it ensures that, after this point, there is no sbupdate that might be journaled so it is safe to update the sb outside thejournal. (To avoid race discussed in 2d01ddc86606)Also, we don't need a similar check in ext4_grp_locked_error since it is onlycalled from mballoc and AFAICT it would be always valid to schedule work here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37812 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:usb: cdns3: Fix deadlock when using NCM gadgetThe cdns3 driver has the same NCM deadlock as fixed in cdnsp by commit58f2fcb3a845 ("usb: cdnsp: Fix deadlock issue during using NCM gadget").Under PREEMPT_RT the deadlock can be readily triggered by heavy networktraffic, for example using "iperf --bidir" over NCM ethernet link.The deadlock occurs because the threaded interrupt handler getspreempted by a softirq, but both are protected by the same spinlock.Prevent deadlock by disabling softirq during threaded irq handler.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37861 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: mpi3mr: Synchronous access b/w reset and tm thread for reply queueWhen the task management thread processes reply queues while the resetthread resets them, the task management thread accesses an invalid queue ID(0xFFFF), set by the reset thread, which points to unallocated memory,causing a crash.Add flag 'io_admin_reset_sync' to synchronize access between the reset,I/O, and admin threads. Before a reset, the reset handler sets this flag toblock I/O and admin processing threads. If any thread bypasses the initialcheck, the reset thread waits up to 10 seconds for processing to finish. Ifthe wait exceeds 10 seconds, the controller is marked as unrecoverable.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38040 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:serial: mctrl_gpio: split disable_ms into sync and no_sync APIsThe following splat has been observed on a SAMA5D27 platform usingatmel_serial:BUG: sleeping function called from invalid context at kernel/irq/manage.c:738in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 27, name: kworker/u5:0preempt_count: 1, expected: 0INFO: lockdep is turned off.irq event stamp: 0hardirqs last enabled at (0): [<00000000>] 0x0hardirqs last disabled at (0): [] copy_process+0x1c4c/0x7becsoftirqs last enabled at (0): [] copy_process+0x1ca0/0x7becsoftirqs last disabled at (0): [<00000000>] 0x0CPU: 0 UID: 0 PID: 27 Comm: kworker/u5:0 Not tainted 6.13.0-rc7+ #74Hardware name: Atmel SAMA5Workqueue: hci0 hci_power_on [bluetooth]Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x44/0x70 dump_stack_lvl from __might_resched+0x38c/0x598 __might_resched from disable_irq+0x1c/0x48 disable_irq from mctrl_gpio_disable_ms+0x74/0xc0 mctrl_gpio_disable_ms from atmel_disable_ms.part.0+0x80/0x1f4 atmel_disable_ms.part.0 from atmel_set_termios+0x764/0x11e8 atmel_set_termios from uart_change_line_settings+0x15c/0x994 uart_change_line_settings from uart_set_termios+0x2b0/0x668 uart_set_termios from tty_set_termios+0x600/0x8ec tty_set_termios from ttyport_set_flow_control+0x188/0x1e0 ttyport_set_flow_control from wilc_setup+0xd0/0x524 [hci_wilc] wilc_setup [hci_wilc] from hci_dev_open_sync+0x330/0x203c [bluetooth] hci_dev_open_sync [bluetooth] from hci_dev_do_open+0x40/0xb0 [bluetooth] hci_dev_do_open [bluetooth] from hci_power_on+0x12c/0x664 [bluetooth] hci_power_on [bluetooth] from process_one_work+0x998/0x1a38 process_one_work from worker_thread+0x6e0/0xfb4 worker_thread from kthread+0x3d4/0x484 kthread from ret_from_fork+0x14/0x28This warning is emitted when trying to toggle, at the highest level,some flow control (with serdev_device_set_flow_control) in a devicedriver. At the lowest level, the atmel_serial driver is usingserial_mctrl_gpio lib to enable/disable the corresponding IRQsaccordingly. The warning emitted by CONFIG_DEBUG_ATOMIC_SLEEP is due todisable_irq (called in mctrl_gpio_disable_ms) being possibly called insome atomic context (some tty drivers perform modem lines configurationin regions protected by port lock).Split mctrl_gpio_disable_ms into two differents APIs, a non-blocking oneand a blocking one. Replace mctrl_gpio_disable_ms calls with therelevant version depending on whether the call is protected by some portlock.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38066 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:dm cache: prevent BUG_ON by blocking retries on failed device resumesA cache device failing to resume due to mapping errors should not beretried, as the failure leaves a partially initialized policy object.Repeating the resume operation risks triggering BUG_ON when reloadingcache mappings into the incomplete policy object.Reproduce steps:1. create a cache metadata consisting of 512 or more cache blocks, with some mappings stored in the first array block of the mapping array. Here we use cache_restore v1.0 to build the metadata.cat <> cmeta.xml EOFdmsetup create cmeta --table "0 8192 linear /dev/sdc 0"cache_restore -i cmeta.xml -o /dev/mapper/cmeta --metadata-version=2dmsetup remove cmeta2. wipe the second array block of the mapping array to simulate data degradations.mapping_root=$(dd if=/dev/sdc bs=1c count=8 skip=192 \2>/dev/null | hexdump -e '1/8 "%u\n"')ablock=$(dd if=/dev/sdc bs=1c count=8 skip=$((4096*mapping_root+2056)) \2>/dev/null | hexdump -e '1/8 "%u\n"')dd if=/dev/zero of=/dev/sdc bs=4k count=1 seek=$ablock3. try bringing up the cache device. The resume is expected to fail due to the broken array block.dmsetup create cmeta --table "0 8192 linear /dev/sdc 0"dmsetup create cdata --table "0 65536 linear /dev/sdc 8192"dmsetup create corig --table "0 524288 linear /dev/sdc 262144"dmsetup create cache --notabledmsetup load cache --table "0 524288 cache /dev/mapper/cmeta \/dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0"dmsetup resume cache4. try resuming the cache again. An unexpected BUG_ON is triggered while loading cache mappings.dmsetup resume cacheKernel logs:(snip)------------[ cut here ]------------kernel BUG at drivers/md/dm-cache-policy-smq.c:752!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 UID: 0 PID: 332 Comm: dmsetup Not tainted 6.13.4 #3RIP: 0010:smq_load_mapping+0x3e5/0x570Fix by disallowing resume operations for devices that failed theinitial attempt.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38073 Severity: Moderate CVSS3 score: 4.1

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38232 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:NFSD: fix race between nfsd registration and exports_procAs of now nfsd calls create_proc_exports_entry() at start of init_nfsdand cleanup by remove_proc_entry() at last of exit_nfsd.Which causes kernel OOPs if there is race between below 2 operations:(i) exportfs -r(ii) mount -t nfsd none /proc/fs/nfsdfor 5.4 kernel ARM64:CPU 1:el1_irq+0xbc/0x180arch_counter_get_cntvct+0x14/0x18running_clock+0xc/0x18preempt_count_add+0x88/0x110prep_new_page+0xb0/0x220get_page_from_freelist+0x2d8/0x1778__alloc_pages_nodemask+0x15c/0xef0__vmalloc_node_range+0x28c/0x478__vmalloc_node_flags_caller+0x8c/0xb0kvmalloc_node+0x88/0xe0nfsd_init_net+0x6c/0x108 [nfsd]ops_init+0x44/0x170register_pernet_operations+0x114/0x270register_pernet_subsys+0x34/0x50init_nfsd+0xa8/0x718 [nfsd]do_one_initcall+0x54/0x2e0CPU 2 :Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010PC is at : exports_net_open+0x50/0x68 [nfsd]Call trace:exports_net_open+0x50/0x68 [nfsd]exports_proc_open+0x2c/0x38 [nfsd]proc_reg_open+0xb8/0x198do_dentry_open+0x1c4/0x418vfs_open+0x38/0x48path_openat+0x28c/0xf18do_filp_open+0x70/0xe8do_sys_open+0x154/0x248Sometimes it crashes at exports_net_open() and sometimes cache_seq_next_rcu().and same is happening on latest 6.14 kernel as well:[ 0.000000] Linux version 6.14.0-rc5-next-20250304-dirty...[ 285.455918] Unable to handle kernel paging request at virtual address 00001f4800001f48...[ 285.464902] pc : cache_seq_next_rcu+0x78/0xa4...[ 285.469695] Call trace:[ 285.470083] cache_seq_next_rcu+0x78/0xa4 (P)[ 285.470488] seq_read+0xe0/0x11c[ 285.470675] proc_reg_read+0x9c/0xf0[ 285.470874] vfs_read+0xc4/0x2fc[ 285.471057] ksys_read+0x6c/0xf4[ 285.471231] __arm64_sys_read+0x1c/0x28[ 285.471428] invoke_syscall+0x44/0x100[ 285.471633] el0_svc_common.constprop.0+0x40/0xe0[ 285.471870] do_el0_svc_compat+0x1c/0x34[ 285.472073] el0_svc_compat+0x2c/0x80[ 285.472265] el0t_32_sync_handler+0x90/0x140[ 285.472473] el0t_32_sync+0x19c/0x1a0[ 285.472887] Code: f9400885 93407c23 937d7c27 11000421 (f86378a3)[ 285.473422] ---[ end trace 0000000000000000 ]---It reproduced simply with below script:while [ 1 ]do/exportfs -rdone &while [ 1 ]doinsmod /nfsd.komount -t nfsd none /proc/fs/nfsdumount /proc/fs/nfsdrmmod nfsddone &So exporting interfaces to user space shall be done at last andcleanup at first place.With change there is no Kernel OOPs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38336 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:ata: pata_via: Force PIO for ATAPI devices on VT6415/VT6330The controller has a hardware bug that can hard hang the system whendoing ATAPI DMAs without any trace of what happened. Depending on thedevice attached, it can also prevent the system from booting.In this case, the system hangs when reading the ATIP from optical mediawith cdrecord -vvv -atip on an _NEC DVD_RW ND-4571A 1-01 and anOptiarc DVD RW AD-7200A 1.06 attached to an ASRock 990FX Extreme 4,running at UDMA/33.The issue can be reproduced by running the same command with a cygwinbuild of cdrecord on WinXP, although it requires more attempts to causeit. The hang in that case is also resolved by forcing PIO. It doesn'tappear that VIA has produced any drivers for that OS, thus no knownworkaround exists.HDDs attached to the controller do not suffer from any DMA issues.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40110 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a null-ptr access in the cursor snooperCheck that the resource which is converted to a surface exists beforetrying to use the cursor snooper on it.vmw_cmd_res_check allows explicit invalid (SVGA3D_INVALID_ID) identifiersbecause some svga commands accept SVGA3D_INVALID_ID to mean "no surface",unfortunately functions that accept the actual surfaces as objects might(and in case of the cursor snooper, do not) be able to handle nullobjects. Make sure that we validate not only the identifier (via thevmw_cmd_res_check) but also check that the actual resource exists beforetrying to do something with it.Fixes unchecked null-ptr reference in the snooping code.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40187 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/sctp: fix a null dereference in sctp_disposition sctp_sf_do_5_1D_ce()If new_asoc->peer.adaptation_ind=0 and sctp_ulpevent_make_authkey=0and sctp_ulpevent_make_authkey() returns 0, then the variableai_ev remains zero and the zero will be dereferencedin the sctp_ulpevent_free() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-53905 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1552, a path traversal issue in Vim's tar.vim plugin can allow overwriting of arbitrary files when opening specially crafted tar archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1552 contains a patch for the vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-53906 Severity: Moderate CVSS3 score: 4.1

Description: Vim is an open source, command line text editor. Prior to version 9.1.1551, a path traversal issue in Vim's zip.vim plugin can allow overwriting of arbitrary files when opening specially crafted zip archives. Impact is low because this exploit requires direct user interaction. However, successfully exploitation can lead to overwriting sensitive files or placing executable code in privileged locations, depending on the permissions of the process editing the archive. The victim must edit such a file using Vim which will reveal the filename and the file content, a careful user may suspect some strange things going on. Successful exploitation could results in the ability to execute arbitrary commands on the underlying operating system. Version 9.1.1551 contains a patch for the vulnerability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-68742 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix invalid prog->stats access when update_effective_progs failsSyzkaller triggers an invalid memory access issue following faultinjection in update_effective_progs. The issue can be described asfollows:__cgroup_bpf_detach update_effective_progs compute_effective_progs bpf_prog_array_alloc <-- fault inject purge_effective_progs /* change to dummy_bpf_prog */ array->items[index] = &dummy_bpf_prog.prog---softirq start---__do_softirq ... __cgroup_bpf_run_filter_skb __bpf_prog_run_save_cb bpf_prog_run stats = this_cpu_ptr(prog->stats) /* invalid memory access */ flags = u64_stats_update_begin_irqsave(&stats->syncp)---softirq end--- static_branch_dec(&cgroup_bpf_enabled_key[atype])The reason is that fault injection caused update_effective_progs to failand then changed the original prog into dummy_bpf_prog.prog inpurge_effective_progs. Then a softirq came, and accessing the members ofdummy_bpf_prog.prog in the softirq triggers invalid mem access.To fix it, skip updating stats when stats is NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-49081 Severity: Moderate CVSS3 score: 4.0

Description: aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation made it possible for an attacker to modify the HTTP request (e.g. to insert a new header) or create a new HTTP request if the attacker controls the HTTP version. The vulnerability only occurs if the attacker can control the HTTP version of the request. This issue has been patched in version 3.9.0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2023-54229 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix registration of 6Ghz-only phy without the full channel rangeBecause of what seems to be a typo, a 6Ghz-only phy for which the BDFdoes not allow the 7115Mhz channel will fail to register: WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954 Modules linked in: ath11k_pci sbsa_gwdt CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9 Hardware name: Freebox V7R Board (DT) Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : wiphy_register+0x914/0x954 lr : ieee80211_register_hw+0x67c/0xc10 sp : ffffff800b123aa0 x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418 x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168 x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014 x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718 x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006 x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284 x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: wiphy_register+0x914/0x954 ieee80211_register_hw+0x67c/0xc10 ath11k_mac_register+0x7c4/0xe10 ath11k_core_qmi_firmware_ready+0x1f4/0x570 ath11k_qmi_driver_event_work+0x198/0x590 process_one_work+0x1b8/0x328 worker_thread+0x6c/0x414 kthread+0x100/0x104 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22 ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22 ath11k_pci 0002:01:00.0: failed to create pdev core: -22

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-7207 Severity: Moderate CVSS3 score: 4.0

Description: Debian's cpio contains a path traversal vulnerability. This issue was introduced by reverting CVE-2015-1197 patches which had caused a regression in --no-absolute-filenames. Upstream has since provided a proper fix to --no-absolute-filenames.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
cpio > 0-0 (version in image is 2.13-150400.3.6.1).

CVE-2024-50171 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:net: systemport: fix potential memory leak in bcm_sysport_xmit()The bcm_sysport_xmit() returns NETDEV_TX_OK without freeing skbin case of dma_map_single() fails, add dev_kfree_skb() to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-0938 Severity: Moderate CVSS3 score: 4.0

Description: The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

CVE-2025-13837 Severity: Moderate CVSS3 score: 4.0

Description: When loading a plist file, the plistlib module reads data in size specified by the file itself, meaning a malicious file can cause OOM and DoS issues

Packages affected:

sle-module-public-cloud-release == 15.4 (version in image is 15.4-150400.55.1).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-38448 Severity: Moderate CVSS3 score: 4.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: u_serial: Fix race condition in TTY wakeupA race condition occurs when gs_start_io() calls either gs_start_rx() orgs_start_tx(), as those functions briefly drop the port_lock forusb_ep_queue(). This allows gs_close() and gserial_disconnect() to clearport.tty and port_usb, respectively.Use the null-safe TTY Port helper function to wake up TTY.Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_rx() // unlock usb_ep_queue() gs_close() // lock, reset port.tty and unlock gs_start_rx() // lock tty_wakeup() // NPE

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-5244 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability was found in GNU Binutils up to 2.44. It has been rated as critical. Affected by this issue is the function elf_gc_sweep of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. Upgrading to version 2.45 is able to address this issue. It is recommended to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-5245 Severity: Moderate CVSS3 score: 4.0

Description: A vulnerability classified as critical has been found in GNU Binutils up to 2.44. This affects the function debug_type_samep of the file /binutils/debug.c of the component objdump. The manipulation leads to memory corruption. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-66382 Severity: Moderate CVSS3 score: 4.0

Description: In libexpat through 2.7.3, a crafted file with an approximate size of 2 MiB can lead to dozens of seconds of processing time.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libexpat1 > 0-0 (version in image is 2.7.1-150400.3.31.1).

CVE-2025-9820 Severity: Moderate CVSS3 score: 4.0

Description: Unknown.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libgnutls30 > 0-0 (version in image is 3.7.3-150400.4.50.1).

CVE-2023-48231 Severity: Low CVSS3 score: 3.9

Description: Vim is an open source command line text editor. When closing a window, vim may try to access already freed window structure. Exploitation beyond crashing the application has not been shown to be viable. This issue has been addressed in commit `25aabc2b` which has been included in release version 9.0.2106. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-48232 Severity: Low CVSS3 score: 3.9

Description: Vim is an open source command line text editor. A floating point exception may occur when calculating the line offset for overlong lines and smooth scrolling is enabled and the cpo-settings include the 'n' flag. This may happen when a window border is present and when the wrapped line continues on the next physical line directly in the window border because the 'cpo' setting includes the 'n' flag. Only users with non-default settings are affected and the exception should only result in a crash. This issue has been addressed in commit `cb0b99f0` which has been included in release version 9.0.2107. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2024-34397 Severity: Low CVSS3 score: 3.8

Description: An issue was discovered in GNOME GLib before 2.78.5, and 2.79.x and 2.80.x before 2.80.1. When a GDBus-based client subscribes to signals from a trusted system service such as NetworkManager on a shared computer, other users of the same computer can send spoofed D-Bus signals that the GDBus-based client will wrongly interpret as having been sent by the trusted system service. This could lead to the GDBus-based client behaving incorrectly, with an application-dependent impact.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2024-36244 Severity: Low CVSS3 score: 3.8

Description: In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: extend minimum interval restriction to entire cycle tooIt is possible for syzbot to side-step the restriction imposed by theblamed commit in the Fixes: tag, because the taprio UAPI permits acycle-time different from (and potentially shorter than) the sum ofentry intervals.We need one more restriction, which is that the cycle time itself mustbe larger than N * ETH_ZLEN bit times, where N is the number of scheduleentries. This restriction needs to apply regardless of whether the cycletime came from the user or was the implicit, auto-calculated value, sowe move the existing "cycle == 0" check outside the "if "(!new->cycle_time)"branch. This way covers both conditions and scenarios.Add a selftest which illustrates the issue triggered by syzbot.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50476 Severity: Moderate CVSS3 score: 3.7

Description: In the Linux kernel, the following vulnerability has been resolved:ntb_netdev: Use dev_kfree_skb_any() in interrupt contextTX/RX callback handlers (ntb_netdev_tx_handler(),ntb_netdev_rx_handler()) can be called in interruptcontext via the DMA framework when the respectiveDMA operations have completed. As such, any callsby these routines to free skb's, should use theinterrupt context safe dev_kfree_skb_any() function.Previously, these callback handlers would call theinterrupt unsafe version of dev_kfree_skb(). This hasnot presented an issue on Intel IOAT DMA engines asthat driver utilizes tasklets rather than a hardinterrupt handler, like the AMD PTDMA DMA driver.On AMD systems, a kernel WARNING message isencountered, which is being issued fromskb_release_head_state() due to in_hardirq()being true.Besides the user visible WARNING from the kernel,the other symptom of this bug was that TCP/IP performanceacross the ntb_netdev interface was very poor, i.e.approximately an order of magnitude below what wasexpected. With the repair to use dev_kfree_skb_any(),kernel WARNINGs from skb_release_head_state() ceasedand TCP/IP performance, as measured by iperf, was onpar with expected results, approximately 20 Gb/s onAMD Milan based server. Note that this performanceis comparable with Intel based servers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-11168 Severity: Low CVSS3 score: 3.7

Description: The urllib.parse.urlsplit() and urlparse() functions improperly validated bracketed hosts (`[]`), allowing hosts that weren't IPv6 or IPvFuture. This behavior was not conformant to RFC 3986 and potentially enabled SSRF if a URL is processed by more than one URL parser.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python3 > 0-0 (version in image is 3.6.15-150300.10.97.2).

CVE-2024-4032 Severity: Low CVSS3 score: 3.7

Description: The "ipaddress" module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as "globally reachable" or "private". This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn't be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-3416 Severity: Low CVSS3 score: 3.7

Description: A flaw was found in OpenSSL's handling of the properties argument in certain functions. This vulnerability can allow use-after-free exploitation, which may result in undefined behavior or incorrect property parsing, leading to OpenSSL treating the input as an empty string.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-cryptography > 0-0 (version in image is 41.0.3-150400.16.22.1).

CVE-2025-53643 Severity: Low CVSS3 score: 3.7

Description: AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2026-0988 Severity: Low CVSS3 score: 3.7

Description: A flaw was found in glib. Missing validation of offset and count parameters in the g_buffered_input_stream_peek() function can lead to an integer overflow during length calculation. When specially crafted values are provided, this overflow results in an incorrect size being passed to memcpy(), triggering a buffer overflow. This can cause application crashes, leading to a Denial of Service (DoS).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
glib2-tools > 0-0 (version in image is 2.70.5-150400.3.23.1).

CVE-2023-48706 Severity: Moderate CVSS3 score: 3.6

Description: Vim is a UNIX editor that, prior to version 9.0.2121, has a heap-use-after-free vulnerability. When executing a `:s` command for the very first time and using a sub-replace-special atom inside the substitution part, it is possible that the recursive `:s` call causes free-ing of memory which may later then be accessed by the initial `:s` command. The user must intentionally execute the payload and the whole process is a bit tricky to do since it seems to work only reliably for the very first :s command. It may also cause a crash of Vim. Version 9.0.2121 contains a fix for this issue.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-38067 Severity: Moderate CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:rseq: Fix segfault on registration when rseq_cs is non-zeroThe rseq_cs field is documented as being set to 0 by user-space prior toregistration, however this is not currently enforced by the kernel. Thiscan result in a segfault on return to user-space if the value stored inthe rseq_cs field doesn't point to a valid struct rseq_cs.The correct solution to this would be to fail the rseq registration whenthe rseq_cs field is non-zero. However, some older versions of glibcwill reuse the rseq area of previous threads without clearing therseq_cs field and will also terminate the process if the rseqregistration fails in a secondary thread. This wasn't caught in testingbecause in this case the leftover rseq_cs does point to a valid structrseq_cs.What we can do is clear the rseq_cs field on registration when it'snon-zero which will prevent segfaults on registration and won't breakthe glibc versions that reuse rseq areas on thread creation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54218 Severity: Low CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: Fix load-tearing on sk->sk_stamp in sock_recv_cmsgs().KCSAN found a data race in sock_recv_cmsgs() where the read accessto sk->sk_stamp needs READ_ONCE().BUG: KCSAN: data-race in packet_recvmsg / packet_recvmsgwrite (marked) to 0xffff88803c81f258 of 8 bytes by task 19171 on cpu 0: sock_write_timestamp include/net/sock.h:2670 [inline] sock_recv_cmsgs include/net/sock.h:2722 [inline] packet_recvmsg+0xb97/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcread to 0xffff88803c81f258 of 8 bytes by task 19183 on cpu 1: sock_recv_cmsgs include/net/sock.h:2721 [inline] packet_recvmsg+0xb64/0xd00 net/packet/af_packet.c:3489 sock_recvmsg_nosec net/socket.c:1019 [inline] sock_recvmsg+0x11a/0x130 net/socket.c:1040 sock_read_iter+0x176/0x220 net/socket.c:1118 call_read_iter include/linux/fs.h:1845 [inline] new_sync_read fs/read_write.c:389 [inline] vfs_read+0x5e0/0x630 fs/read_write.c:470 ksys_read+0x163/0x1a0 fs/read_write.c:613 __do_sys_read fs/read_write.c:623 [inline] __se_sys_read fs/read_write.c:621 [inline] __x64_sys_read+0x41/0x50 fs/read_write.c:621 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdcvalue changed: 0xffffffffc4653600 -> 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 19183 Comm: syz-executor.5 Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40999 Severity: Low CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:net: ena: Add validation for completion descriptors consistencyValidate that `first` flag is set only for the firstdescriptor in multi-buffer packets.In case of an invalid descriptor, a reset will occur.A new reset reason for RX data corruption has been added.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1147 Severity: Low CVSS3 score: 3.6

Description: A vulnerability has been found in GNU Binutils 2.43 and classified as problematic. Affected by this vulnerability is the function __sanitizer::internal_strlen of the file binutils/nm.c of the component nm. The manipulation of the argument const leads to buffer overflow. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-40026 Severity: Low CVSS3 score: 3.6

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: x86: Don't (re)check L1 intercepts when completing userspace I/OWhen completing emulation of instruction that generated a userspace exitfor I/O, don't recheck L1 intercepts as KVM has already finished thatphase of instruction execution, i.e. has already committed to allowing L2to perform I/O. If L1 (or host userspace) modifies the I/O permissionbitmaps during the exit to userspace, KVM will treat the access as beingintercepted despite already having emulated the I/O access.Pivot on EMULTYPE_NO_DECODE to detect that KVM is completing emulation.Of the three users of EMULTYPE_NO_DECODE, only complete_emulated_io() (theintended "recipient") can reach the code in question. gp_interception()'suse is mutually exclusive with is_guest_mode(), andcomplete_emulated_insn_gp() unconditionally pairs EMULTYPE_NO_DECODE withEMULTYPE_SKIP.The bad behavior was detected by a syzkaller program that toggles port I/Ointerception during the userspace I/O exit, ultimately resulting in a WARNon vcpu->arch.pio.count being non-zero due to KVM no completing emulationof the I/O instruction. WARNING: CPU: 23 PID: 1083 at arch/x86/kvm/x86.c:8039 emulator_pio_in_out+0x154/0x170 [kvm] Modules linked in: kvm_intel kvm irqbypass CPU: 23 UID: 1000 PID: 1083 Comm: repro Not tainted 6.16.0-rc5-c1610d2d66b1-next-vm #74 NONE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:emulator_pio_in_out+0x154/0x170 [kvm] PKRU: 55555554 Call Trace: kvm_fast_pio+0xd6/0x1d0 [kvm] vmx_handle_exit+0x149/0x610 [kvm_intel] kvm_arch_vcpu_ioctl_run+0xda8/0x1ac0 [kvm] kvm_vcpu_ioctl+0x244/0x8c0 [kvm] __x64_sys_ioctl+0x8a/0xd0 do_syscall_64+0x5d/0xc60 entry_SYSCALL_64_after_hwframe+0x4b/0x53

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-2004 Severity: Moderate CVSS3 score: 3.5

Description: When a protocol selection parameter option disables all protocols without adding any then the default set of protocols would remain in the allowed set due to an error in the logic for removing protocols. The below command would perform a request to curl.se with a plaintext protocol which has been explicitly disabled. curl --proto -all,-http http://curl.se The flaw is only present if the set of selected protocols disables the entire set of available protocols, in itself a command with no practical use and therefore unlikely to be encountered in real situations. The curl security team has thus assessed this to be low severity bug.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2023-52698 Severity: Moderate CVSS3 score: 3.4

Description: In the Linux kernel, the following vulnerability has been resolved:calipso: fix memory leak in netlbl_calipso_add_pass()If IPv6 support is disabled at boot (ipv6.disable=1),the calipso_init() -> netlbl_calipso_ops_register() function isn't called,and the netlbl_calipso_ops_get() function always returns NULL.In this case, the netlbl_calipso_add_pass() function allocates memoryfor the doi_def variable but doesn't free it with the calipso_doi_free().BUG: memory leakunreferenced object 0xffff888011d68180 (size 64): comm "syz-executor.1", pid 10746, jiffies 4295410986 (age 17.928s) hex dump (first 32 bytes): 00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<...>] kmalloc include/linux/slab.h:552 [inline] [<...>] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline] [<...>] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111 [<...>] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739 [<...>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline] [<...>] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800 [<...>] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515 [<...>] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811 [<...>] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] [<...>] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339 [<...>] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934 [<...>] sock_sendmsg_nosec net/socket.c:651 [inline] [<...>] sock_sendmsg+0x157/0x190 net/socket.c:671 [<...>] ____sys_sendmsg+0x712/0x870 net/socket.c:2342 [<...>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396 [<...>] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429 [<...>] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46 [<...>] entry_SYSCALL_64_after_hwframe+0x61/0xc6Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller[PM: merged via the LSM tree at Jakub Kicinski request]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38047 Severity: Moderate CVSS3 score: 3.4

Description: In the Linux kernel, the following vulnerability has been resolved:x86/fred: Fix system hang during S4 resume with FRED enabledUpon a wakeup from S4, the restore kernel starts and initializes theFRED MSRs as needed from its perspective. It then loads a hibernationimage, including the image kernel, and attempts to load image pagesdirectly into their original page frames used before hibernation unlessthose frames are currently in use. Once all pages are moved to theiroriginal locations, it jumps to a "trampoline" page in the image kernel.At this point, the image kernel takes control, but the FRED MSRs stillcontain values set by the restore kernel, which may differ from thoseset by the image kernel before hibernation. Therefore, the image kernelmust ensure the FRED MSRs have the same values as before hibernation.Since these values depend only on the location of the kernel text anddata, they can be recomputed from scratch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48844 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix leaking sent_cmd skbsent_cmd memory is not freed before freeing hci_dev causing it to leakit contents.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49780 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: tcm_loop: Fix possible name leak in tcm_loop_setup_hba_bus()If device_register() fails in tcm_loop_setup_hba_bus(), the name allocatedby dev_set_name() need be freed. As comment of device_register() says, itshould use put_device() to give up the reference in the error path. So fixthis by calling put_device(), then the name can be freed in kobject_cleanup().The 'tl_hba' will be freed in tcm_loop_release_adapter(), so it don't needgoto error label in this case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49817 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: mhi: Fix memory leak in mhi_net_dellink()MHI driver registers network device without setting theneeds_free_netdev flag, and does NOT call free_netdev() whenunregisters network device, which causes a memory leak.This patch calls free_netdev() to fix it since netdev_privis used after unregister.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49829 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/scheduler: fix fence ref countingWe leaked dependency fences when processes were beeing killed.Additional to that grab a reference to the last scheduled fence.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52652 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:NTB: fix possible name leak in ntb_register_device()If device_register() fails in ntb_register_device(), the device nameallocated by dev_set_name() should be freed. As per the comment indevice_register(), callers should use put_device() to give up thereference in the error path. So fix this by calling put_device() in theerror path so that the name can be freed in kobject_cleanup().As a result of this, put_device() in the error path ofntb_register_device() is removed and the actual error is returned.[mani: reworded commit message]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52653 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:SUNRPC: fix a memleak in gss_import_v2_contextThe ctx->mech_used.data allocated by kmemdup is not freed in neithergss_import_v2_context nor it only caller gss_krb5_import_sec_context,which frees ctx on error.Thus, this patch reform the last call of gss_import_v2_context to thegss_krb5_import_ctx_v2, preventing the memleak while keepping the returnformation.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52835 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Bail out early if the request AUX area is out of boundWhen perf-record with a large AUX area, e.g 4GB, it fails with: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)and it reveals a WARNING with __alloc_pages(): ------------[ cut here ]------------ WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248 Call trace: __alloc_pages+0x1ec/0x248 __kmalloc_large_node+0xc0/0x1f8 __kmalloc_node+0x134/0x1e8 rb_alloc_aux+0xe0/0x298 perf_mmap+0x440/0x660 mmap_region+0x308/0x8a8 do_mmap+0x3c0/0x528 vm_mmap_pgoff+0xf4/0x1b8 ksys_mmap_pgoff+0x18c/0x218 __arm64_sys_mmap+0x38/0x58 invoke_syscall+0x50/0x128 el0_svc_common.constprop.0+0x58/0x188 do_el0_svc+0x34/0x50 el0_svc+0x34/0x108 el0t_64_sync_handler+0xb8/0xc0 el0t_64_sync+0x1a4/0x1a8'rb->aux_pages' allocated by kcalloc() is a pointer array which is used tomaintains AUX trace pages. The allocated page for this array is physicallycontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If thesize of pointer array crosses the limitation set by MAX_ORDER, it reveals aWARNING.So bail out early with -ENOMEM if the request AUX area is out of bound,e.g.: #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1 failed to mmap with 12 (Cannot allocate memory)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53649 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf trace: Really free the evsel->priv areaIn 3cb4d5e00e037c70 ("perf trace: Free syscall tp fields inevsel->priv") it only was freeing if strcmp(evsel->tp_format->system,"syscalls") returned zero, while the corresponding initialization ofevsel->priv was being performed if it was _not_ zero, i.e. if the tpsystem wasn't 'syscalls'.Just stop looking for that and free it if evsel->priv was set, whichshould be equivalent.Also use the pre-existing evsel_trace__delete() function.This resolves these leaks, detected with: $ make EXTRA_CFLAGS="-fsanitize=address" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin ================================================================= ==481565==ERROR: LeakSanitizer: detected memory leaks Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212 #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) Direct leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097) #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966) #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307 #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333 #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458 #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480 #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205 #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891 #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156 #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323 #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377 #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421 #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537 #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f) SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s). [root@quaco ~]#With this we plug all leaks with "perf trace sleep 1".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53683 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:fs: hfsplus: remove WARN_ON() from hfsplus_cat_{read,write}_inode()syzbot is hitting WARN_ON() in hfsplus_cat_{read,write}_inode(), forcrafted filesystem image can contain bogus length. There conditions arenot kernel bugs that can justify kernel to panic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54267 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Rework lppaca_shared_proc() to avoid DEBUG_PREEMPTlppaca_shared_proc() takes a pointer to the lppaca which is typicallyaccessed through get_lppaca(). With DEBUG_PREEMPT enabled, this leadsto checking if preemption is enabled, for example: BUG: using smp_processor_id() in preemptible [00000000] code: grep/10693 caller is lparcfg_data+0x408/0x19a0 CPU: 4 PID: 10693 Comm: grep Not tainted 6.5.0-rc3 #2 Call Trace: dump_stack_lvl+0x154/0x200 (unreliable) check_preemption_disabled+0x214/0x220 lparcfg_data+0x408/0x19a0 ...This isn't actually a problem however, as it does not matter whichlppaca is accessed, the shared proc state will be the same.vcpudispatch_stats_procfs_init() already works around this by disablingpreemption, but the lparcfg code does not, erroring any time/proc/powerpc/lparcfg is accessed with DEBUG_PREEMPT enabled.Instead of disabling preemption on the caller side, reworklppaca_shared_proc() to not take a pointer and instead directly accessthe lppaca, bypassing any potential preemption checks.[mpe: Rework to avoid needing a definition in paca.h and lppaca.h]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26743 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/qedr: Fix qedr_create_user_qp error flowAvoid the following warning by making sure to free the allocatedresources in case that qedr_init_user_queue() fail.-----------[ cut here ]-----------WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Modules linked in: tls target_core_user uio target_core_pscsi target_core_file target_core_iblock ib_srpt ib_srp scsi_transport_srp nfsd nfs_acl rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs 8021q garp mrp stp llc ext4 mbcache jbd2 opa_vnic ib_umad ib_ipoib sunrpc rdma_ucm ib_isert iscsi_target_mod target_core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm iw_cm ib_cm hfi1 intel_rapl_msr intel_rapl_common mgag200 qedr sb_edac drm_shmem_helper rdmavt x86_pkg_temp_thermal drm_kms_helper intel_powerclamp ib_uverbs coretemp i2c_algo_bit kvm_intel dell_wmi_descriptor ipmi_ssif sparse_keymap kvm ib_core rfkill syscopyarea sysfillrect video sysimgblt irqbypass ipmi_si ipmi_devintf fb_sys_fops rapl iTCO_wdt mxm_wmi iTCO_vendor_support intel_cstate pcspkr dcdbas intel_uncore ipmi_msghandler lpc_ich acpi_power_meter mei_me mei fuse drm xfs libcrc32c qede sd_mod ahci libahci t10_pi sg crct10dif_pclmul crc32_pclmul crc32c_intel qed libata tg3ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]Code: 5d 41 5c 41 5d 41 5e e9 0f 26 1b dd 48 89 df e8 67 6a ff ff 49 8b 86 10 01 00 00 48 85 c0 74 9c 4c 89 e7 e8 83 c0 cb dd eb 92 <0f> 0b eb be 0f 0b be 04 00 00 00 48 89 df e8 8e f5 ff ff e9 6d ffRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0Call Trace:? show_trace_log_lvl+0x1c4/0x2df? show_trace_log_lvl+0x1c4/0x2df? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? __warn+0x81/0x110? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]? report_bug+0x10a/0x140? handle_bug+0x3c/0x70? exc_invalid_op+0x14/0x70? asm_exc_invalid_op+0x16/0x20? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]ib_uverbs_close+0x1f/0xb0 [ib_uverbs]__fput+0x94/0x250task_work_run+0x5c/0x90do_exit+0x270/0x4a0do_group_exit+0x2d/0x90get_signal+0x87c/0x8c0arch_do_signal_or_restart+0x25/0x100? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]exit_to_user_mode_loop+0x9c/0x130exit_to_user_mode_prepare+0xb6/0x100syscall_exit_to_user_mode+0x12/0x40do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? syscall_exit_work+0x103/0x130? syscall_exit_to_user_mode+0x22/0x40? do_syscall_64+0x69/0x90? do_syscall_64+0x69/0x90? common_interrupt+0x43/0xa0entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x1470abe3ec6bCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6bRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470--[ end trace 888a9b92e04c5c97 ]--

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26877 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: xilinx - call finalize with bh disabledWhen calling crypto_finalize_request, BH should be disabled to avoidtriggering the following calltrace: ------------[ cut here ]------------ WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118 Modules linked in: cryptodev(O) CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G O 6.8.0-rc1-yocto-standard #323 Hardware name: ZynqMP ZCU102 Rev1.0 (DT) pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : crypto_finalize_request+0xa0/0x118 lr : crypto_finalize_request+0x104/0x118 sp : ffffffc085353ce0 x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688 x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00 x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000 x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0 x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8 x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001 x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000 x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000 Call trace: crypto_finalize_request+0xa0/0x118 crypto_finalize_aead_request+0x18/0x30 zynqmp_handle_aes_req+0xcc/0x388 crypto_pump_work+0x168/0x2d8 kthread_worker_fn+0xfc/0x3a0 kthread+0x118/0x138 ret_from_fork+0x10/0x20 irq event stamp: 40 hardirqs last enabled at (39): [] _raw_spin_unlock_irqrestore+0x70/0xb0 hardirqs last disabled at (40): [] el1_dbg+0x28/0x90 softirqs last enabled at (36): [] kernel_neon_begin+0x8c/0xf0 softirqs last disabled at (34): [] kernel_neon_begin+0x60/0xf0 ---[ end trace 0000000000000000 ]---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26901 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1]"BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40 instrument_copy_to_user include/linux/instrumented.h:114 [inline] _copy_to_user+0xbc/0x100 lib/usercopy.c:40 copy_to_user include/linux/uaccess.h:191 [inline] do_sys_name_to_handle fs/fhandle.c:73 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Uninit was created at: slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768 slab_alloc_node mm/slub.c:3478 [inline] __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517 __do_kmalloc_node mm/slab_common.c:1006 [inline] __kmalloc+0x121/0x3c0 mm/slab_common.c:1020 kmalloc include/linux/slab.h:604 [inline] do_sys_name_to_handle fs/fhandle.c:39 [inline] __do_sys_name_to_handle_at fs/fhandle.c:112 [inline] __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94 ...Bytes 18-19 of 20 are uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240"Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() tosolve the problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26937 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Reset queue_priority_hint on parkingOriginally, with strict in order execution, we could complete executiononly when the queue was empty. Preempt-to-busy allows replacement of anactive request that may complete before the preemption is processed byHW. If that happens, the request is retired from the queue, but thequeue_priority_hint remains set, preventing direct submission untilafter the next CS interrupt is processed.This preempt-to-busy race can be triggered by the heartbeat, which willalso act as the power-management barrier and upon completion allow us toidle the HW. We may process the completion of the heartbeat, and beginparking the engine before the CS event that restores thequeue_priority_hint, causing us to fail the assertion that it is MIN.<3>[ 166.210729] __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))<0>[ 166.210781] Dumping ftrace buffer:<0>[ 166.210795] ---------------------------------...<0>[ 167.302811] drm_fdin-1097 2..s1. 165741070us : trace_ports: 0000:00:02.0 rcs0: promote { ccid:20 1217:2 prio 0 }<0>[ 167.302861] drm_fdin-1097 2d.s2. 165741072us : execlists_submission_tasklet: 0000:00:02.0 rcs0: preempting last=1217:2, prio=0, hint=2147483646<0>[ 167.302928] drm_fdin-1097 2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0<0>[ 167.302992] drm_fdin-1097 2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659<0>[ 167.303044] drm_fdin-1097 2d.s1. 165741076us : execlists_submission_tasklet: 0000:00:02.0 rcs0: context:3 schedule-in, ccid:40<0>[ 167.303095] drm_fdin-1097 2d.s1. 165741077us : trace_ports: 0000:00:02.0 rcs0: submit { ccid:40 3:4660* prio 2147483646 }<0>[ 167.303159] kworker/-89 11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2<0>[ 167.303208] kworker/-89 11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin<0>[ 167.303272] kworker/-89 11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2<0>[ 167.303321] kworker/-89 11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin<0>[ 167.303384] kworker/-89 11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660<0>[ 167.303434] kworker/-89 11d..1. 165741172us : __intel_context_retire: 0000:00:02.0 rcs0: context:1216 retire runtime: { total:56028ns, avg:56028ns }<0>[ 167.303484] kworker/-89 11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked<0>[ 167.303534] -0 5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040<0>[ 167.303583] kworker/-89 11..... 165741397us : __intel_context_retire: 0000:00:02.0 rcs0: context:1217 retire runtime: { total:325575ns, avg:0ns }<0>[ 167.303756] kworker/-89 11..... 165741777us : __intel_context_retire: 0000:00:02.0 rcs0: context:c90 retire runtime: { total:0ns, avg:0ns }<0>[ 167.303806] kworker/-89 11..... 165742017us : __engine_park: __engine_park:283 GEM_BUG_ON(engine->sched_engine->queue_priority_hint != (-((int)(~0U >> 1)) - 1))<0>[ 167.303811] ---------------------------------<4>[ 167.304722] ------------[ cut here ]------------<2>[ 167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!<4>[ 167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<4>[ 167.304734] CPU: 11 PID: 89 Comm: kworker/11:1 Tainted: G W 6.8.0-rc2-CI_DRM_14193-gc655e0fd2804+ #1<4>[ 167.304736] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022<4>[ 167.304738] Workqueue: i915-unordered retire_work_handler [i915]<4>[ 16---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27000 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: mxs-auart: add spinlock around changing cts stateThe uart_handle_cts_change() function in serial_core expects the callerto hold uport->lock. For example, I have seen the below kernel splat,when the Bluetooth driver is loaded on an i.MX28 board. [ 85.119255] ------------[ cut here ]------------ [ 85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec [ 85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs [ 85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1 [ 85.151396] Hardware name: Freescale MXS (Device Tree) [ 85.156679] Workqueue: hci0 hci_power_on [bluetooth] (...) [ 85.191765] uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4 [ 85.198787] mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210 (...)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-27004 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Get runtime PM before walking tree during disable_unusedDoug reported [1] the following hung task: INFO: task swapper/0:1 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:swapper/0 state:D stack: 0 pid: 1 ppid: 0 flags:0x00000008 Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c rpm_resume+0xe0/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 clk_pm_runtime_get+0x30/0xb0 clk_disable_unused_subtree+0x58/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused_subtree+0x38/0x208 clk_disable_unused+0x4c/0xe4 do_one_initcall+0xcc/0x2d8 do_initcall_level+0xa4/0x148 do_initcalls+0x5c/0x9c do_basic_setup+0x24/0x30 kernel_init_freeable+0xec/0x164 kernel_init+0x28/0x120 ret_from_fork+0x10/0x20 INFO: task kworker/u16:0:9 blocked for more than 122 seconds. Not tainted 5.15.149-21875-gf795ebc40eb8 #1 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:kworker/u16:0 state:D stack: 0 pid: 9 ppid: 2 flags:0x00000008 Workqueue: events_unbound deferred_probe_work_func Call trace: __switch_to+0xf4/0x1f4 __schedule+0x418/0xb80 schedule+0x5c/0x10c schedule_preempt_disabled+0x2c/0x48 __mutex_lock+0x238/0x488 __mutex_lock_slowpath+0x1c/0x28 mutex_lock+0x50/0x74 clk_prepare_lock+0x7c/0x9c clk_core_prepare_lock+0x20/0x44 clk_prepare+0x24/0x30 clk_bulk_prepare+0x40/0xb0 mdss_runtime_resume+0x54/0x1c8 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x108/0x1f4 __rpm_callback+0x84/0x144 rpm_callback+0x30/0x88 rpm_resume+0x1f4/0x52c rpm_resume+0x178/0x52c __pm_runtime_resume+0x58/0x98 __device_attach+0xe0/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c device_add+0x644/0x814 mipi_dsi_device_register_full+0xe4/0x170 devm_mipi_dsi_device_register_full+0x28/0x70 ti_sn_bridge_probe+0x1dc/0x2c0 auxiliary_bus_probe+0x4c/0x94 really_probe+0xcc/0x2c8 __driver_probe_device+0xa8/0x130 driver_probe_device+0x48/0x110 __device_attach_driver+0xa4/0xcc bus_for_each_drv+0x8c/0xd8 __device_attach+0xf8/0x170 device_initial_probe+0x1c/0x28 bus_probe_device+0x3c/0x9c deferred_probe_work_func+0x9c/0xd8 process_one_work+0x148/0x518 worker_thread+0x138/0x350 kthread+0x138/0x1e0 ret_from_fork+0x10/0x20The first thread is walking the clk tree and callingclk_pm_runtime_get() to power on devices required to read the clkhardware via struct clk_ops::is_enabled(). This thread holds the clkprepare_lock, and is trying to runtime PM resume a device, when it findsthat the device is in the process of resuming so the thread schedule()saway waiting for the device to finish resuming before continuing. Thesecond thread is runtime PM resuming the same device, but the runtimeresume callback is calling clk_prepare(), trying to grab theprepare_lock waiting on the first thread.This is a classic ABBA deadlock. To properly fix the deadlock, we mustnever runtime PM resume or suspend a device with the clk prepare_lockheld. Actually doing that is near impossible today because the globalprepare_lock would have to be dropped in the middle of the tree, thedevice runtime PM resumed/suspended, and then the prepare_lock grabbedagain to ensure consistency of the clk tree topology. If anythingchanges with the clk tree in the meantime, we've lost and will need tostart the operation all over again.Luckily, most of the time we're simply incrementing or decrementing theruntime PM count on an active device, so we don't have the chance toschedule away with the prepare_lock held. Let's fix this immediateproblem that can be---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35937 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there's another subframe in the A-MSDUbut the header isn't fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-37078 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential kernel bug due to lack of writeback flag waitingDestructive writes to a block device on which nilfs2 is mounted can causea kernel bug in the folio/page writeback start routine or writeback endroutine (__folio_start_writeback in the log below): kernel BUG at mm/page-writeback.c:3070! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI ... RIP: 0010:__folio_start_writeback+0xbaa/0x10e0 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 <0f> 0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00 ... Call Trace: nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2] nilfs_segctor_construct+0x181/0x6b0 [nilfs2] nilfs_segctor_thread+0x548/0x11c0 [nilfs2] kthread+0x2f0/0x390 ret_from_fork+0x4b/0x80 ret_from_fork_asm+0x1a/0x30 This is because when the log writer starts a writeback for segment summaryblocks or a super root block that use the backing device's page cache, itdoes not wait for the ongoing folio/page writeback, resulting in aninconsistent writeback state.Fix this issue by waiting for ongoing writebacks when puttingfolios/pages on the backing device into writeback state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39489 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix memleak in seg6_hmac_init_algoseg6_hmac_init_algo returns without cleaning up the previous allocationsif one fails, so it's going to leak all that memory and the crypto tfms.Update seg6_hmac_exit to only free the memory when allocated, so we canreuse the code directly.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-39490 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix missing sk_buff release in seg6_input_coreThe seg6_input() function is responsible for adding the SRH into apacket, delegating the operation to the seg6_input_core(). This functionuses the skb_cow_head() to ensure that there is sufficient headroom inthe sk_buff for accommodating the link-layer header.In the event that the skb_cow_header() function fails, theseg6_input_core() catches the error but it does not release the sk_buff,which will result in a memory leak.This issue was introduced in commit af3b5158b89d ("ipv6: sr: fix BUG dueto headroom too small after SRH push") and persists even after commit7a3f5b0de364 ("netfilter: add netfilter hooks to SRv6 data plane"),where the entire seg6_input() code was refactored to deal with netfilterhooks.The proposed patch addresses the identified memory leak by requiring theseg6_input_core() function to release the sk_buff in the event thatskb_cow_head() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41013 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xfs: don't walk off the end of a directory data blockThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entryto make sure don't stray beyond valid memory region. Before patching, theloop simply checks that the start offset of the dup and dep is within therange. So in a crafted image, if last entry is xfs_dir2_data_unused, wecan change dup->length to dup->length-1 and leave 1 byte of space. In thenext traversal, this space will be considered as dup or dep. We mayencounter an out of bound read when accessing the fixed members.In the patch, we make sure that the remaining bytes large enough to holdan unused entry before accessing xfs_dir2_data_unused andxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also makesure that the remaining bytes large enough to hold a dirent with asingle-byte name before accessing xfs_dir2_data_entry.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41015 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_check_dir_entry()This adds sanity checks for ocfs2_dir_entry to make sure all members ofocfs2_dir_entry don't stray beyond valid memory region.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41068 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix sclp_init() cleanup on failureIf sclp_init() fails it only partially cleans up: if there are multiplefailing calls to sclp_init() sclp_state_change_event will be added severaltimes to sclp_reg_list, which results in the following warning:------------[ cut here ]------------list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8) R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3...Call Trace: [<000003ffe0d6076a>] __list_add_valid_or_report+0xe2/0xf8([<000003ffe0d60766>] __list_add_valid_or_report+0xde/0xf8) [<000003ffe0a8d37e>] sclp_init+0x40e/0x450 [<000003ffe00009f2>] do_one_initcall+0x42/0x1e0 [<000003ffe15b77a6>] do_initcalls+0x126/0x150 [<000003ffe15b7a0a>] kernel_init_freeable+0x1ba/0x1f8 [<000003ffe0d6650e>] kernel_init+0x2e/0x180 [<000003ffe000301c>] __ret_from_fork+0x3c/0x60 [<000003ffe0d759ca>] ret_from_fork+0xa/0x30Fix this by removing sclp_state_change_event from sclp_reg_list whensclp_init() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42070 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registersregister store validation for NFT_DATA_VALUE is conditional, however,the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. Thisonly requires a new helper function to infer the register type from theset datatype so this conditional check can be removed. Otherwise,pointer to chain object can be leaked through the registers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42087 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleepThe ilitek-ili9881c controls the reset GPIO using the non-sleepinggpiod_set_value() function. This complains loudly when the GPIOcontroller needs to sleep. As the caller can sleep, usegpiod_set_value_cansleep() to fix the issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-42311 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()Syzbot reports uninitialized value access issue as below:loop0: detected capacity change from 0 to 64=====================================================BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30 d_revalidate fs/namei.c:862 [inline] lookup_fast+0x89e/0x8e0 fs/namei.c:1649 walk_component fs/namei.c:2001 [inline] link_path_walk+0x817/0x1480 fs/namei.c:2332 path_lookupat+0xd9/0x6f0 fs/namei.c:2485 filename_lookup+0x22e/0x740 fs/namei.c:2515 user_path_at_empty+0x8b/0x390 fs/namei.c:2924 user_path_at include/linux/namei.h:57 [inline] do_mount fs/namespace.c:3689 [inline] __do_sys_mount fs/namespace.c:3898 [inline] __se_sys_mount+0x66b/0x810 fs/namespace.c:3875 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bBUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 hfs_ext_read_extent fs/hfs/extent.c:196 [inline] hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553 do_read_cache_page mm/filemap.c:3595 [inline] read_cache_page+0xfb/0x2f0 mm/filemap.c:3604 read_mapping_page include/linux/pagemap.h:755 [inline] hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406 mount_bdev+0x628/0x920 fs/super.c:1359 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145 path_mount+0xf98/0x26a0 fs/namespace.c:3475 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline] __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246 entry_SYSENTER_compat_after_hwframe+0x70/0x82Uninit was created at: __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590 __alloc_pages_node include/linux/gfp.h:238 [inline] alloc_pages_node include/linux/gfp.h:261 [inline] alloc_slab_page mm/slub.c:2190 [inline] allocate_slab mm/slub.c:2354 [inline] new_slab+0x2d7/0x1400 mm/slub.c:2407 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540 __slab_alloc mm/slub.c:3625 [inline] __slab_alloc_node mm/slub.c:3678 [inline] slab_alloc_node mm/slub.c:3850 [inline] kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879 alloc_inode_sb include/linux/fs.h:3018 [inline] hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165 alloc_inode+0x83/0x440 fs/inode.c:260 new_inode_pseudo fs/inode.c:1005 [inline] new_inode+0x38/0x4f0 fs/inode.c:1031 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228 vfs_mkdir+0x49a/0x700 fs/namei.c:4126 do_mkdirat+0x529/0x810 fs/namei.c:4149 __do_sys_mkdirat fs/namei.c:4164 [inline] __se_sys_mkdirat fs/namei.c:4162 [inline] __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6bIt missed to initialize .tz_secondswest, .cached_start and .cached_blocksfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45009 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only decrement add_addr_accepted for MPJ reqAdding the following warning ... WARN_ON_ONCE(msk->pm.add_addr_accepted == 0)... before decrementing the add_addr_accepted counter helped to find abug when running the "remove single subflow" subtest from themptcp_join.sh selftest.Removing a 'subflow' endpoint will first trigger a RM_ADDR, then thesubflow closure. Before this patch, and upon the reception of theRM_ADDR, the other peer will then try to decrement thisadd_addr_accepted. That's not correct because the attached subflows havenot been created upon the reception of an ADD_ADDR.A way to solve that is to decrement the counter only if the attachedsubflow was an MP_JOIN to a remote id that was not 0, and initiated bythe host receiving the RM_ADDR.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-45010 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: only mark 'subflow' endp as availableAdding the following warning ... WARN_ON_ONCE(msk->pm.local_addr_used == 0)... before decrementing the local_addr_used counter helped to find a bugwhen running the "remove single address" subtest from the mptcp_join.shselftests.Removing a 'signal' endpoint will trigger the removal of all subflowslinked to this endpoint via mptcp_pm_nl_rm_addr_or_subflow() withrm_type == MPTCP_MIB_RMSUBFLOW. This will decrement the local_addr_usedcounter, which is wrong in this case because this counter is linked to'subflow' endpoints, and here it is a 'signal' endpoint that is beingremoved.Now, the counter is decremented, only if the ID is being used outsideof mptcp_pm_nl_rm_addr_or_subflow(), only for 'subflow' endpoints, andif the ID is not 0 -- local_addr_used is not taking into account theseones. This marking of the ID as being available, and the decrement isdone no matter if a subflow using this ID is currently available,because the subflow could have been closed before.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47671 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:USB: usbtmc: prevent kernel-usb-infoleakThe syzbot reported a kernel-usb-infoleak in usbtmc_write,we need to clear the structure before filling fields.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47672 Severity: Moderate CVSS3 score: 3.3

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47673 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedNot doing so will make us send a host command to the transport while thefirmware is not alive, which will trigger a WARNING.bad state = 0WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]Call Trace: iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50134 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLAReplace the fake VLA at end of the vbva_mouse_pointer_shape shape witha real VLA to fix a "memcpy: detected field-spanning write error" warning:[ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4)[ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo][ 13.320038] Call Trace:[ 13.320173] hgsmi_update_pointer_shape [vboxvideo][ 13.320184] vbox_cursor_atomic_update [vboxvideo]Note as mentioned in the added comment it seems the original lengthcalculation for the allocated and send hgsmi buffer is 4 bytes too large.Changing this is not the goal of this patch, so this behavior is kept.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-50236 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath10k: Fix memory leak in management txIn the current logic, memory is allocated for storing the MSDU contextduring management packet TX but this memory is not being freed duringmanagement TX completion. Similar leaks are seen in the management TXcleanup logic.Kmemleak reports this problem as below,unreferenced object 0xffffff80b64ed250 (size 16): comm "kworker/u16:7", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20Free the memory during completion and cleanup to fix the leak.Protect the mgmt_pending_tx idr_remove() operation inath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar toother instances.Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53195 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Get rid of userspace_irqchip_in_useImproper use of userspace_irqchip_in_use led to syzbot hitting thefollowing WARN_ON() in kvm_timer_update_irq():WARNING: CPU: 0 PID: 3281 at arch/arm64/kvm/arch_timer.c:459kvm_timer_update_irq+0x21c/0x394Call trace: kvm_timer_update_irq+0x21c/0x394 arch/arm64/kvm/arch_timer.c:459 kvm_timer_vcpu_reset+0x158/0x684 arch/arm64/kvm/arch_timer.c:968 kvm_reset_vcpu+0x3b4/0x560 arch/arm64/kvm/reset.c:264 kvm_vcpu_set_target arch/arm64/kvm/arm.c:1553 [inline] kvm_arch_vcpu_ioctl_vcpu_init arch/arm64/kvm/arm.c:1573 [inline] kvm_arch_vcpu_ioctl+0x112c/0x1b3c arch/arm64/kvm/arm.c:1695 kvm_vcpu_ioctl+0x4ec/0xf74 virt/kvm/kvm_main.c:4658 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x108/0x184 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x78/0x1b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0xe8/0x1b0 arch/arm64/kernel/syscall.c:132 do_el0_svc+0x40/0x50 arch/arm64/kernel/syscall.c:151 el0_svc+0x54/0x14c arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The following sequence led to the scenario: - Userspace creates a VM and a vCPU. - The vCPU is initialized with KVM_ARM_VCPU_PMU_V3 during KVM_ARM_VCPU_INIT. - Without any other setup, such as vGIC or vPMU, userspace issues KVM_RUN on the vCPU. Since the vPMU is requested, but not setup, kvm_arm_pmu_v3_enable() fails in kvm_arch_vcpu_run_pid_change(). As a result, KVM_RUN returns after enabling the timer, but before incrementing 'userspace_irqchip_in_use': kvm_arch_vcpu_run_pid_change() ret = kvm_arm_pmu_v3_enable() if (!vcpu->arch.pmu.created) return -EINVAL; if (ret) return ret; [...] if (!irqchip_in_kernel(kvm)) static_branch_inc(&userspace_irqchip_in_use); - Userspace ignores the error and issues KVM_ARM_VCPU_INIT again. Since the timer is already enabled, control moves through the following flow, ultimately hitting the WARN_ON(): kvm_timer_vcpu_reset() if (timer->enabled) kvm_timer_update_irq() if (!userspace_irqchip()) ret = kvm_vgic_inject_irq() ret = vgic_lazy_init() if (unlikely(!vgic_initialized(kvm))) if (kvm->arch.vgic.vgic_model != KVM_DEV_TYPE_ARM_VGIC_V2) return -EBUSY; WARN_ON(ret);Theoretically, since userspace_irqchip_in_use's functionality can besimply replaced by '!irqchip_in_kernel()', get rid of the static keyto avoid the mismanagement, which also helps with the syzbot issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53198 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xen: Fix the issue of resource not being properly released in xenbus_dev_probe()This patch fixes an issue in the function xenbus_dev_probe(). In thexenbus_dev_probe() function, within the if (err) branch at line 313, theprogram incorrectly returns err directly without releasing the resourcesallocated by err = drv->probe(dev, id). As the return value is non-zero,the upper layers assume the processing logic has failed. However, the probeoperation was performed earlier without a corresponding remove operation.Since the probe actually allocates resources, failing to perform the removeoperation could lead to problems.To fix this issue, we followed the resource release logic of thexenbus_dev_remove() function by adding a new block fail_remove before thefail_put block. After entering the branch if (err) at line 313, thefunction will use a goto statement to jump to the fail_remove block,ensuring that the previously acquired resources are correctly released,thus preventing the reference count leak.This bug was identified by an experimental static analysis tool developedby our team. The tool specializes in analyzing reference count operationsand detecting potential issues where resources are not properly managed.In this case, the tool flagged the missing release operation as apotential problem, which led to the development of this patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56751 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ipv6: release nexthop on device removalThe CI is hitting some aperiodic hangup at device removal time in thepmtu.sh self-test:unregister_netdevice: waiting for veth_A-R1 to become free. Usage count = 6ref_tracker: veth_A-R1@ffff888013df15d8 has 1/5 users at dst_init+0x84/0x4a0 dst_alloc+0x97/0x150 ip6_dst_alloc+0x23/0x90 ip6_rt_pcpu_alloc+0x1e6/0x520 ip6_pol_route+0x56f/0x840 fib6_rule_lookup+0x334/0x630 ip6_route_output_flags+0x259/0x480 ip6_dst_lookup_tail.constprop.0+0x5c2/0x940 ip6_dst_lookup_flow+0x88/0x190 udp_tunnel6_dst_lookup+0x2a7/0x4c0 vxlan_xmit_one+0xbde/0x4a50 [vxlan] vxlan_xmit+0x9ad/0xf20 [vxlan] dev_hard_start_xmit+0x10e/0x360 __dev_queue_xmit+0xf95/0x18c0 arp_solicit+0x4a2/0xe00 neigh_probe+0xaa/0xf0While the first suspect is the dst_cache, explicitly tracking the dstowing the last device reference via probes proved such dst is held bythe nexthop in the originating fib6_info.Similar to commit f5b51fe804ec ("ipv6: route: purge exception onremoval"), we need to explicitly release the originating fib info whendisconnecting a to-be-removed device from a live ipv6 dst: move thefib6_info cleanup into ip6_dst_ifdown().Tested running:./pmtu.sh cleanup_ipv6_exceptionin a tight loop for more than 400 iterations with no spat, running anunpatched kernel I observed a splat every ~10 iterations.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57908 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: imu: kmx61: fix information leak in triggered bufferThe 'buffer' local array is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57910 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: light: vcnl4035: fix information leak in triggered bufferThe 'buffer' local array is used to push data to userspace from atriggered buffer, but it does not set an initial value for the singledata element, which is an u16 aligned to 8 bytes. That leaves at least4 bytes uninitialized even after writing an integer value withregmap_read().Initialize the array to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57912 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: pressure: zpa2326: fix information leak in triggered bufferThe 'sample' local struct is used to push data to user space from atriggered buffer, but it has a hole between the temperature and thetimestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).This hole is never initialized.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1372 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability was found in GNU elfutils 0.192. It has been declared as critical. Affected by this vulnerability is the function dump_data_section/print_string_section of the file readelf.c of the component eu-readelf. The manipulation of the argument z/x leads to buffer overflow. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is 73db9d2021cab9e23fd734b0a76a612d52a6f1db. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).

CVE-2025-21981 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ice: fix memory leak in aRFS after resetFix aRFS (accelerated Receive Flow Steering) structures memory leak byadding a checker to verify if aRFS memory is already allocated whileconfiguring VSI. aRFS objects are allocated in two cases:- as part of VSI initialization (at probe), and- as part of reset handlingHowever, VSI reconfiguration executed during reset involves memoryallocation one more time, without prior releasing already allocatedresources. This led to the memory leak with the following signature:[root@os-delivery ~]# cat /sys/kernel/debug/kmemleakunreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [] __kmalloc_cache_noprof+0x275/0x340 [] ice_init_arfs+0x3a/0xe0 [ice] [] ice_vsi_cfg_def+0x607/0x850 [ice] [] ice_vsi_setup+0x5b/0x130 [ice] [] ice_init+0x1c1/0x460 [ice] [] ice_probe+0x2af/0x520 [ice] [] local_pci_probe+0x43/0xa0 [] work_for_cpu_fn+0x13/0x20 [] process_one_work+0x179/0x390 [] worker_thread+0x239/0x340 [] kthread+0xcc/0x100 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30 ...

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-3198 Severity: Moderate CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.43/2.44 and classified as problematic. Affected by this vulnerability is the function display_info of the file binutils/bucomm.c of the component objdump. The manipulation leads to memory leak. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The patch is named ba6ad3a18cb26b79e0e3b84c39f707535bbc344d. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-37839 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:jbd2: remove wrong sb->s_sequence checkJournal emptiness is not determined by sb->s_sequence == 0 but rather bysb->s_start == 0 (which is set a few lines above). Furthermore 0 is avalid transaction ID so the check can spuriously trigger. Remove theinvalid WARN_ON.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37859 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:page_pool: avoid infinite loop to schedule delayed workerWe noticed the kworker in page_pool_release_retry() was wakenup repeatedly and infinitely in production because of thebuggy driver causing the inflight less than 0 and warningus in page_pool_inflight()[1].Since the inflight value goes negative, it means we shouldnot expect the whole page_pool to get back to work normally.This patch mitigates the adverse effect by not reschedulingthe kworker when detecting the inflight negative inpage_pool_release_retry().[1][Mon Feb 10 20:36:11 2025] ------------[ cut here ]------------[Mon Feb 10 20:36:11 2025] Negative(-51446) inflight packet-pages...[Mon Feb 10 20:36:11 2025] Call Trace:[Mon Feb 10 20:36:11 2025] page_pool_release_retry+0x23/0x70[Mon Feb 10 20:36:11 2025] process_one_work+0x1b1/0x370[Mon Feb 10 20:36:11 2025] worker_thread+0x37/0x3a0[Mon Feb 10 20:36:11 2025] kthread+0x11a/0x140[Mon Feb 10 20:36:11 2025] ? process_one_work+0x370/0x370[Mon Feb 10 20:36:11 2025] ? __kthread_cancel_work+0x40/0x40[Mon Feb 10 20:36:11 2025] ret_from_fork+0x35/0x40[Mon Feb 10 20:36:11 2025] ---[ end trace ebffe800f33e7e34 ]---Note: before this patch, the above calltrace would flood thedmesg due to repeated reschedule of release_dw kworker.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37909 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: lan743x: Fix memleak issue when GSO enabledAlways map the `skb` to the LS descriptor. Previously skb wasmapped to EXT descriptor when the number of fragments is zero withGSO enabled. Mapping the skb to EXT descriptor prevents it frombeing freed, leading to a memory leak

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38099 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Disable SCO support if READ_VOICE_SETTING is unsupported/brokenA SCO connection without the proper voice_setting can causethe controller to lock up.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38528 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject %p% format string in bprintf-like helpersstatic const char fmt[] = "%p%"; bpf_trace_printk(fmt, sizeof(fmt));The above BPF program isn't rejected and causes a kernel warning atruntime: Please remove unsupported %\x00 in format string WARNING: CPU: 1 PID: 7244 at lib/vsprintf.c:2680 format_decode+0x49c/0x5d0This happens because bpf_bprintf_prepare skips over the second %,detected as punctuation, while processing %p. This patch fixes it bynot skipping over punctuation. %\x00 is then processed in the nextiteration and rejected.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40057 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ptp: Add a upper bound on max_vclockssyzbot reported WARNING in max_vclocks_store.This occurs when the argument max is too large for kcalloc to handle.Extend the guard to guard against values that are too large forkcalloc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71119 Severity: Moderate CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kexec: Enable SMT before waking offline CPUsIf SMT is disabled or a partial SMT state is enabled, when a new kernelimage is loaded for kexec, on reboot the following warning is observed:kexec: Waking offline cpu 228.WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc[snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ecThis occurs as add_cpu() fails due to cpu_bootable() returning false forCPUs that fail the cpu_smt_thread_allowed() check or non primarythreads if SMT is disabled.Fix the issue by enabling SMT and resetting the number of SMT threads tothe number of threads per core, before attempting to wake up all presentCPUs.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2026-0989 Severity: Moderate CVSS3 score: 3.3

Description: A flaw was identified in the RelaxNG parser of libxml2 related to how external schema inclusions are handled. The parser does not enforce a limit on inclusion depth when resolving nested directives. Specially crafted or overly complex schemas can cause excessive recursion during parsing. This may lead to stack exhaustion and application crashes, creating a denial-of-service risk.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2026-0992 Severity: Moderate CVSS3 score: 3.3

Description: A flaw was found in the libxml2 library. This uncontrolled resource consumption vulnerability occurs when processing XML catalogs that contain repeated elements pointing to the same downstream catalog. A remote attacker can exploit this by supplying crafted catalogs, causing the parser to redundantly traverse catalog chains. This leads to excessive CPU consumption and degrades application availability, resulting in a denial-of-service condition.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2019-19925 Severity: Low CVSS3 score: 3.3

Description: zipfileUpdate in ext/misc/zipfile.c in SQLite 3.30.1 mishandles a NULL pathname during an update of a ZIP archive.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
sqlite3-tcl > 0-0 (version in image is 3.50.2-150000.3.33.1).

CVE-2022-48642 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()It seems to me that percpu memory for chain stats started leaking sincecommit 3bc158f8d0330f0a ("netfilter: nf_tables: map basechain priority tohardware priority") when nft_chain_offload_priority() returned an error.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48698 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: fix memory leak when using debugfs_lookup()When calling debugfs_lookup() the result must have dput() called on it,otherwise the memory will leak over time. Fix this up by properlycalling dput().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48808 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: fix panic when DSA master device unbinds on shutdownRafael reports that on a system with LX2160A and Marvell DSA switches,if a reboot occurs while the DSA master (dpaa2-eth) is up, the followingpanic can be seen:systemd-shutdown[1]: Rebooting.Unable to handle kernel paging request at virtual address 00a0000800000041[00a0000800000041] address between user and kernel address rangesInternal error: Oops: 96000004 [#1] PREEMPT SMPCPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32pc : dsa_slave_netdevice_event+0x130/0x3e4lr : raw_notifier_call_chain+0x50/0x6cCall trace: dsa_slave_netdevice_event+0x130/0x3e4 raw_notifier_call_chain+0x50/0x6c call_netdevice_notifiers_info+0x54/0xa0 __dev_close_many+0x50/0x130 dev_close_many+0x84/0x120 unregister_netdevice_many+0x130/0x710 unregister_netdevice_queue+0x8c/0xd0 unregister_netdev+0x20/0x30 dpaa2_eth_remove+0x68/0x190 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver_internal+0xac/0xb0 device_links_unbind_consumers+0xd4/0x100 __device_release_driver+0x94/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_device_remove+0x24/0x40 __fsl_mc_device_remove+0xc/0x20 device_for_each_child+0x58/0xa0 dprc_remove+0x90/0xb0 fsl_mc_driver_remove+0x20/0x5c __device_release_driver+0x21c/0x220 device_release_driver+0x28/0x40 bus_remove_device+0x118/0x124 device_del+0x174/0x420 fsl_mc_bus_remove+0x80/0x100 fsl_mc_bus_shutdown+0xc/0x1c platform_shutdown+0x20/0x30 device_shutdown+0x154/0x330 __do_sys_reboot+0x1cc/0x250 __arm64_sys_reboot+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x4c/0x150 el0_svc+0x24/0xb0 el0t_64_sync_handler+0xa8/0xb0 el0t_64_sync+0x178/0x17cIt can be seen from the stack trace that the problem is that thederegistration of the master causes a dev_close(), which gets notifiedas NETDEV_GOING_DOWN to dsa_slave_netdevice_event().But dsa_switch_shutdown() has already run, and this has unregistered theDSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts tocall dev_close_many() on those slave interfaces, leading to the problem.The previous attempt to avoid the NETDEV_GOING_DOWN on the master afterdsa_switch_shutdown() was called seems improper. Unregistering the slaveinterfaces is unnecessary and unhelpful. Instead, after the slaves havestopped being uppers of the DSA master, we can now reset to NULL themaster->dsa_ptr pointer, which will make DSA start ignoring all futurenotifier events on the master.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49020 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net/9p: Fix a potential socket leak in p9_socket_openBoth p9_fd_create_tcp() and p9_fd_create_unix() will callp9_socket_open(). If the creation of p9_trans_fd fails,p9_fd_create_tcp() and p9_fd_create_unix() will return anerror directly instead of releasing the cscoket, which willresult in a socket leak.This patch adds sock_release() to fix the leak issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49539 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:rtw89: ser: fix CAM leaks occurring in L2 resetThe CAM, meaning address CAM and bssid CAM here, will get leaks duringSER (system error recover) L2 reset process and ieee80211_restart_hw()which is called by L2 reset process eventually.The normal flow would be like-> add interface (acquire 1)-> enter ips (release 1)-> leave ips (acquire 1)-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>The ieee80211_restart_hw() flow (under connection)-> ieee80211 reconfig-> add interface (acquire 1)-> leave ips (acquire 1)-> connection (occupy (A) + 2) <(B) 1 more leak>Originally, CAM is released before HW restart only if connection is undersecurity. Now, release CAM whatever connection it is to fix leak in (A).OTOH, check if CAM is already valid to avoid acquiring multiple times tofix (B).Besides, if AP mode, release address CAM of all stations before HW restart.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49619 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: sfp: fix memory leak in sfp_probe()sfp_probe() allocates a memory chunk from sfp with sfp_alloc(). Whendevm_add_action() fails, sfp is not freed, which leads to a memory leak.We should use devm_add_action_or_reset() instead of devm_add_action().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49620 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: tipc: fix possible refcount leak in tipc_sk_create()Free sk in case tipc_sk_insert() fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49837 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix memory leaks in __check_func_callkmemleak reports this issue:unreferenced object 0xffff88817139d000 (size 2048): comm "test_progs", pid 33246, jiffies 4307381979 (age 45851.820s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000045f075f0>] kmalloc_trace+0x27/0xa0 [<0000000098b7c90a>] __check_func_call+0x316/0x1230 [<00000000b4c3c403>] check_helper_call+0x172e/0x4700 [<00000000aa3875b7>] do_check+0x21d8/0x45e0 [<000000001147357b>] do_check_common+0x767/0xaf0 [<00000000b5a595b4>] bpf_check+0x43e3/0x5bc0 [<0000000011e391b1>] bpf_prog_load+0xf26/0x1940 [<0000000007f765c0>] __sys_bpf+0xd2c/0x3650 [<00000000839815d6>] __x64_sys_bpf+0x75/0xc0 [<00000000946ee250>] do_syscall_64+0x3b/0x90 [<0000000000506b7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcdThe root case here is: In function prepare_func_exit(), the callee isnot released in the abnormal scenario after "state->curframe--;". Tofix, move "state->curframe--;" to the very bottom of the function,right when we free callee and reset frame[] pointer to NULL, as Andriisuggested.In addition, function __check_func_call() has a similar problem. Inthe abnormal scenario before "state->curframe++;", the callee alsoshould be released by free_func_state().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49979 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: fix refcount bug in sk_psock_get (2)Syzkaller reports refcount bug as follows:------------[ cut here ]------------refcount_t: saturated; leaking memory.WARNING: CPU: 1 PID: 3605 at lib/refcount.c:19 refcount_warn_saturate+0xf4/0x1e0 lib/refcount.c:19Modules linked in:CPU: 1 PID: 3605 Comm: syz-executor208 Not tainted 5.18.0-syzkaller-03023-g7e062cda7d90 #0 __refcount_add_not_zero include/linux/refcount.h:163 [inline] __refcount_inc_not_zero include/linux/refcount.h:227 [inline] refcount_inc_not_zero include/linux/refcount.h:245 [inline] sk_psock_get+0x3bc/0x410 include/linux/skmsg.h:439 tls_data_ready+0x6d/0x1b0 net/tls/tls_sw.c:2091 tcp_data_ready+0x106/0x520 net/ipv4/tcp_input.c:4983 tcp_data_queue+0x25f2/0x4c90 net/ipv4/tcp_input.c:5057 tcp_rcv_state_process+0x1774/0x4e80 net/ipv4/tcp_input.c:6659 tcp_v4_do_rcv+0x339/0x980 net/ipv4/tcp_ipv4.c:1682 sk_backlog_rcv include/net/sock.h:1061 [inline] __release_sock+0x134/0x3b0 net/core/sock.c:2849 release_sock+0x54/0x1b0 net/core/sock.c:3404 inet_shutdown+0x1e0/0x430 net/ipv4/af_inet.c:909 __sys_shutdown_sock net/socket.c:2331 [inline] __sys_shutdown_sock net/socket.c:2325 [inline] __sys_shutdown+0xf1/0x1b0 net/socket.c:2343 __do_sys_shutdown net/socket.c:2351 [inline] __se_sys_shutdown net/socket.c:2349 [inline] __x64_sys_shutdown+0x50/0x70 net/socket.c:2349 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 During SMC fallback process in connect syscall, kernel willreplaces TCP with SMC. In order to forward wakeupsmc socket waitqueue after fallback, kernel will setsclcsk->sk_user_data to origin smc socket insmc_fback_replace_callbacks().Later, in shutdown syscall, kernel will callssk_psock_get(), which treats the clcsk->sk_user_dataas psock type, triggering the refcnt warning.So, the root cause is that smc and psock, both will usesk_user_data field. So they will mismatch this fieldeasily.This patch solves it by using another bit(defined asSK_USER_DATA_PSOCK) in PTRMASK, to mark whethersk_user_data points to a psock object or not.This patch depends on a PTRMASK introduced in commit f1ff5ce2cd5e("net, sk_msg: Clear sk_user_data pointer on clone if tagged").For there will possibly be more flags in the sk_user_data field,this patch also refactor sk_user_data flags code to be more genericto improve its maintainability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50025 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:cxl: Fix a memory leak in an error handling pathA bitmap_zalloc() must be balanced by a corresponding bitmap_free() in theerror handling path of afu_allocate_irqs().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50420 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/hpre - fix resource leak in remove processIn hpre_remove(), when the disable operation of qm sriov failed,the following logic should continue to be executed to release theremaining resources that have been allocated, instead of returningdirectly, otherwise there will be resource leakage.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50480 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:memory: pl353-smc: Fix refcount leak bug in pl353_smc_probe()The break of for_each_available_child_of_node() needs acorresponding of_node_put() when the reference 'child' is notused anymore. Here we do not need to call of_node_put() infail path as '!match' means no break.While the of_platform_device_create() will created a newreference by 'child' but it has considered the refcounting.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50489 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mipi-dsi: Detach devices when removing the hostWhenever the MIPI-DSI host is unregistered, the code ofmipi_dsi_host_unregister() loops over every device currently found on thatbus and will unregister it.However, it doesn't detach it from the bus first, which leads to all kindof resource leaks if the host wants to perform some clean up whenever adevice is detached.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50513 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:staging: rtl8723bs: fix a potential memory leak in rtw_init_cmd_priv()In rtw_init_cmd_priv(), if `pcmdpriv->rsp_allocated_buf` is allocatedin failure, then `pcmdpriv->cmd_allocated_buf` will be not properlyreleased. Besides, considering there are only two error paths and thefirst one can directly return, so we do not need implicitly jump to the`exit` tag to execute the error handler.So this patch added `kfree(pcmdpriv->cmd_allocated_buf);` on the errorpath to release the resource and simplified the return logic ofrtw_init_cmd_priv(). As there is no proper device to test with, no runtimetesting was performed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50541 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflowUDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.These registers are 32-bit hardware counters and the driver uses thesecounters to monitor the operational progress status for a channel, whentransferring more than 4GB of data it was observed that these countersoverflow and completion calculation of a operation gets affected and thetransfer hangs indefinitely.This commit adds changes to decrease the byte count for every completetransaction so that these registers never overflow and the proper bytecount statistics is maintained for ongoing transaction by the RT counters.Earlier uc->bcnt used to maintain a count of the completed bytes at driverside, since the RT counters maintain the statistics of current transactionnow, the maintenance of uc->bcnt is not necessary.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50582 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: core: Prevent integer underflowBy using a ratio of delay to poll_enabled_time that is not integertime_remaining underflows and does not exit the loop as expected.As delay could be derived from DT and poll_enabled_time is definedin the driver this can easily happen.Use a signed iterator to make sure that the loop exits oncethe remaining time is negative.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50645 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:EDAC/i10nm: fix refcount leak in pci_get_dev_wrapper()As the comment of pci_get_domain_bus_and_slot() says, it returnsa PCI device with refcount incremented, so it doesn't need tocall an extra pci_dev_get() in pci_get_dev_wrapper(), and the PCIdevice needs to be put in the error path.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50663 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: stmmac: fix possible memory leak in stmmac_dvr_probe()The bitmap_free() should be called to free priv->af_xdp_zc_qpswhen create_singlethread_workqueue() fails, otherwise there willbe a memory leak, so we add the err path error_wq_init to fix it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50759 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: i2c: ov5648: Free V4L2 fwnode data on unbindThe V4L2 fwnode data structure doesn't get freed on unbind, which leads toa memleak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50772 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netdevsim: fix memory leak in nsim_bus_dev_new()If device_register() failed in nsim_bus_dev_new(), the value of referencein nsim_bus_dev->dev is 1. obj->name in nsim_bus_dev->dev will not bereleased.unreferenced object 0xffff88810352c480 (size 16): comm "echo", pid 5691, jiffies 4294945921 (age 133.270s) hex dump (first 16 bytes): 6e 65 74 64 65 76 73 69 6d 31 00 00 00 00 00 00 netdevsim1...... backtrace: [<000000005e2e5e26>] __kmalloc_node_track_caller+0x3a/0xb0 [<0000000094ca4fc8>] kvasprintf+0xc3/0x160 [<00000000aad09bcc>] kvasprintf_const+0x55/0x180 [<000000009bac868d>] kobject_set_name_vargs+0x56/0x150 [<000000007c1a5d70>] dev_set_name+0xbb/0xf0 [<00000000ad0d126b>] device_add+0x1f8/0x1cb0 [<00000000c222ae24>] new_device_store+0x3b6/0x5e0 [<0000000043593421>] bus_attr_store+0x72/0xa0 [<00000000cbb1833a>] sysfs_kf_write+0x106/0x160 [<00000000d0dedb8a>] kernfs_fop_write_iter+0x3a8/0x5a0 [<00000000770b66e2>] vfs_write+0x8f0/0xc80 [<0000000078bb39be>] ksys_write+0x106/0x210 [<00000000005e55a4>] do_syscall_64+0x35/0x80 [<00000000eaa40bbc>] entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-45918 Severity: Low CVSS3 score: 3.3

Description: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libncurses6 > 0-0 (version in image is 6.1-150000.5.30.1).

CVE-2023-53271 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ubi: Fix unreferenced object reported by kmemleak in ubi_resize_volume()There is a memory leaks problem reported by kmemleak:unreferenced object 0xffff888102007a00 (size 128): comm "ubirsvol", pid 32090, jiffies 4298464136 (age 2361.231s) hex dump (first 32 bytes):ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace:[] __kmalloc+0x4d/0x150[] ubi_eba_create_table+0x76/0x170 [ubi][] ubi_resize_volume+0x1be/0xbc0 [ubi][] ubi_cdev_ioctl+0x701/0x1850 [ubi][] __x64_sys_ioctl+0x11d/0x170[] do_syscall_64+0x35/0x80[] entry_SYSCALL_64_after_hwframe+0x46/0xb0This is due to a mismatch between create and destroy interfaces, andin detail that "new_eba_tbl" created by ubi_eba_create_table() butdestroyed by kfree(), while will causing "new_eba_tbl->entries" notfreed.Fix it by replacing kfree(new_eba_tbl) withubi_eba_destroy_table(new_eba_tbl)

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53529 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rtw88: Fix memory leak in rtw88_usbKmemleak shows the following leak arising from routine in the usbprobe routine:unreferenced object 0xffff895cb29bba00 (size 512): comm "(udev-worker)", pid 534, jiffies 4294903932 (age 102751.088s) hex dump (first 32 bytes): 77 30 30 30 00 00 00 00 02 2f 2d 2b 30 00 00 00 w000...../-+0... 02 00 2a 28 00 00 00 00 ff 55 ff ff ff 00 00 00 ..*(.....U...... backtrace: [] kmalloc_trace+0x26/0x90 [] rtw_usb_probe+0x2f1/0x680 [rtw_usb] [] usb_probe_interface+0xdd/0x2e0 [usbcore] [] really_probe+0x18e/0x3d0 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xbf/0x1b0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x10e/0x210 [] driver_register+0x55/0xf0 [] usb_register_driver+0x88/0x140 [usbcore] [] do_one_initcall+0x43/0x210 [] do_init_module+0x4a/0x200 [] __do_sys_finit_module+0xac/0x120 [] do_syscall_64+0x56/0x80 [] entry_SYSCALL_64_after_hwframe+0x46/0xb0The leak was verified to be real by unloading the driver, which resultedin a dangling pointer to the allocation.The allocated memory is freed in rtw_usb_intf_deinit().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53592 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:gpio: sifive: Fix refcount leak in sifive_gpio_probeof_irq_find_parent() returns a node pointer with refcount incremented,We should use of_node_put() on it when not needed anymore.Add missing of_node_put() to avoid refcount leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53605 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm: amd: display: Fix memory leakageThis commit fixes memory leakage in dc_construct_ctx() function.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53670 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-core: fix dev_pm_qos memleakCall dev_pm_qos_hide_latency_tolerance() in the error unwind patch toavoid following kmemleak:-blktests (master) # kmemleak-clear; ./check nvme/044;blktests (master) # kmemleak-scan ; kmemleak-shownvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124sunreferenced object 0xffff888110c46240 (size 96): comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloc_trace+0x25/0x90 [<000000006acc66d5>] dev_pm_qos_update_user_latency_tolerance+0x6f/0x100 [<00000000cc376ea7>] nvme_init_ctrl+0x38e/0x410 [nvme_core] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfs_write+0xc5/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53674 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clk: Fix memory leak in devm_clk_notifier_register()devm_clk_notifier_register() allocates a devres resource for clknotifier but didn't register that to the device, so the notifier didn'tget unregistered on device detach and the allocated resource was leaked.Fix the issue by registering the resource through devres_add().This issue was found with kmemleak on a Chromebook.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53682 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (xgene) Fix ioremap and memremap leakSmatch reports:drivers/hwmon/xgene-hwmon.c:757 xgene_hwmon_probe() warn:'ctx->pcc_comm_addr' from ioremap() not released on line: 757.This is because in drivers/hwmon/xgene-hwmon.c:701 xgene_hwmon_probe(),ioremap and memremap is not released, which may cause a leak.To fix this, ioremap and memremap is modified to devm_ioremap anddevm_memremap.[groeck: Fixed formatting and subject]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53685 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:tun: Fix memory leak for detached NAPI queue.syzkaller reported [0] memory leaks of sk and skb related to the TUNdevice with no repro, but we can reproduce it easily with: struct ifreq ifr = {} int fd_tun, fd_tmp; char buf[4] = {}; fd_tun = openat(AT_FDCWD, "/dev/net/tun", O_WRONLY, 0); ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE; ioctl(fd_tun, TUNSETIFF, &ifr); ifr.ifr_flags = IFF_DETACH_QUEUE; ioctl(fd_tun, TUNSETQUEUE, &ifr); fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0); ifr.ifr_flags = IFF_UP; ioctl(fd_tmp, SIOCSIFFLAGS, &ifr); write(fd_tun, buf, sizeof(buf)); close(fd_tun);If we enable NAPI and multi-queue on a TUN device, we can put skb intotfile->sk.sk_write_queue after the queue is detached. We should preventit by checking tfile->detached before queuing skb.Note this must be done under tfile->sk.sk_write_queue.lock because write()and ioctl(IFF_DETACH_QUEUE) can run concurrently. Otherwise, there wouldbe a small race window: write() ioctl(IFF_DETACH_QUEUE) `- tun_get_user `- __tun_detach |- if (tfile->detached) |- tun_disable_queue | `-> false | `- tfile->detached = tun | `- tun_queue_purge |- spin_lock_bh(&queue->lock) `- __skb_queue_tail(queue, skb)Another solution is to call tun_queue_purge() when closing andreattaching the detached queue, but it could paper over anotherproblems. Also, we do the same kind of test for IFF_NAPI_FRAGS.[0]:unreferenced object 0xffff88801edbc800 (size 2048): comm "syz-executor.1", pid 33269, jiffies 4295743834 (age 18.756s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............ backtrace: [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline] [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979 [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline] [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035 [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088 [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438 [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165 [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414 [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920 [<000000008eb24774>] do_open fs/namei.c:3636 [inline] [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791 [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818 [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356 [<00000000057be699>] do_sys_open fs/open.c:1372 [inline] [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline] [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline] [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383 [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80 [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff88802f671700 (size 240): comm "syz-executor.1", pid 33269, jiffies 4295743854 (age 18.736s) hex dump (first 32 bytes): 68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff h.......h....... 00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff ..{/............ backtrace: [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644 [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline] [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378 [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729 [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline] [<---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53687 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() when iterating clkWhen the best clk is searched, we iterate over all possible clk.If we find a better match, the previous one, if any, needs to be freed.If a better match has already been found, we still need to free the newone, otherwise it leaks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53704 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx: clk-imx8mp: improve error handling in imx8mp_clocks_probe()Replace of_iomap() and kzalloc() with devm_of_iomap() and devm_kzalloc()which can automatically release the related memory when the deviceor driver is removed or unloaded to avoid potential memory leak.In this case, iounmap(anatop_base) in line 427,433 are removedas manual release is not required.Besides, referring to clk-imx8mq.c, check the return code ofof_clk_add_hw_provider, if it returns negtive, print error infoand unregister hws, which makes the program more robust.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53708 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ACPI: x86: s2idle: Catch multiple ACPI_TYPE_PACKAGE objectsIf a badly constructed firmware includes multiple `ACPI_TYPE_PACKAGE`objects while evaluating the AMD LPS0 _DSM, there will be a memoryleak. Explicitly guard against this.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53719 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:serial: arc_uart: fix of_iomap leak in `arc_serial_probe`Smatch reports:drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:'port->membase' from of_iomap() not released on lines: 631.In arc_serial_probe(), if uart_add_one_port() fails,port->membase is not released, which would cause a resource leak.To fix this, I replace of_iomap with devm_platform_ioremap_resource.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53723 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspendsdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,driver unconditionally disables ecc_irq which is only enabled onthose asics enabling sdma ecc. This will introduce a warning insuspend cycle on those chips with sdma ip v4.0, while withoutsdma ecc. So this patch correct this.[ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu][ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246[ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000[ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000[ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006[ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390[ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105[ 7283.167032] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000[ 7283.167036] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0[ 7283.167041] Call Trace:[ 7283.167046] [ 7283.167048] sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu][ 7283.167704] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu][ 7283.168296] amdgpu_device_suspend+0x103/0x180 [amdgpu][ 7283.168875] amdgpu_pmops_freeze+0x21/0x60 [amdgpu][ 7283.169464] pci_pm_freeze+0x54/0xc0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53724 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()`req` is allocated in pcf50633_adc_async_read(), butadc_enqueue_request() could fail to insert the `req` into queue.We need to check the return value and free it in the case of failure.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53725 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probeSmatch reports:drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.timer_baseaddr may have the problem of not being released after use,I replaced it with the devm_of_iomap() function and added the clk_put()function to cleanup the "clk_ce" and "clk_cs".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53733 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knodeWhen u32_replace_hw_knode fails, we need to undo the tcf_bind_filteroperation done at u32_set_parms.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54105 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:can: isotp: check CAN address family in isotp_bind()Add missing check to block non-AF_CAN binds.Syzbot created some code which matched the right sockaddr struct sizebut used AF_XDP (0x2C) instead of AF_CAN (0x1D) in the address familyfield:bind$xdp(r2, &(0x7f0000000540)={0x2c, 0x0, r4, 0x0, r2}, 0x10) ^^^^This has no funtional impact but the userspace should be notified aboutthe wrong address family field content.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54180 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: handle case when repair happens with dev-replace[BUG]There is a bug report that a BUG_ON() in btrfs_repair_io_failure()(originally repair_io_failure() in v6.0 kernel) got triggered whenreplacing a unreliable disk: BTRFS warning (device sda1): csum failed root 257 ino 2397453 off 39624704 csum 0xb0d18c75 expected csum 0x4dae9c5e mirror 3 kernel BUG at fs/btrfs/extent_io.c:2380! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 9 PID: 3614331 Comm: kworker/u257:2 Tainted: G OE 6.0.0-5-amd64 #1 Debian 6.0.10-2 Hardware name: Micro-Star International Co., Ltd. MS-7C60/TRX40 PRO WIFI (MS-7C60), BIOS 2.70 07/01/2021 Workqueue: btrfs-endio btrfs_end_bio_work [btrfs] RIP: 0010:repair_io_failure+0x24a/0x260 [btrfs] Call Trace: clean_io_failure+0x14d/0x180 [btrfs] end_bio_extent_readpage+0x412/0x6e0 [btrfs] ? __switch_to+0x106/0x420 process_one_work+0x1c7/0x380 worker_thread+0x4d/0x380 ? rescuer_thread+0x3a0/0x3a0 kthread+0xe9/0x110 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30[CAUSE]Before the BUG_ON(), we got some read errors from the replace targetfirst, note the mirror number (3, which is beyond RAID1 duplication,thus it's read from the replace target device).Then at the BUG_ON() location, we are trying to writeback the repairedsectors back the failed device.The check looks like this: ret = btrfs_map_block(fs_info, BTRFS_MAP_WRITE, logical, &map_length, &bioc, mirror_num); if (ret) goto out_counter_dec; BUG_ON(mirror_num != bioc->mirror_num);But inside btrfs_map_block(), we can modify bioc->mirror_num especiallyfor dev-replace: if (dev_replace_is_ongoing && mirror_num == map->num_stripes + 1 && !need_full_stripe(op) && dev_replace->tgtdev != NULL) { ret = get_extra_mirror_from_replace(fs_info, logical, *length, dev_replace->srcdev->devid, &mirror_num, &physical_to_patch_in_first_stripe); patch_the_first_stripe_for_dev_replace = 1; }Thus if we're repairing the replace target device, we're going totrigger that BUG_ON().But in reality, the read failure from the replace target device may bethat, our replace hasn't reached the range we're reading, thus we'rereading garbage, but with replace running, the range would be properlyfilled later.Thus in that case, we don't need to do anything but let the replaceroutine to handle it.[FIX]Instead of a BUG_ON(), just skip the repair if we're repairing thedevice replace target device.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54194 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: use kvmalloc_array/kvfree instead of kmalloc_array/kfreeThe call stack shown below is a scenario in the Linux 4.19 kernel.Allocating memory failed where exfat fs use kmalloc_array due tosystem memory fragmentation, while the u-disk was inserted withoutrecognition.Devices such as u-disk using the exfat file system are pluggable andmay be insert into the system at any time.However, long-term running systems cannot guarantee the continuity ofphysical memory. Therefore, it's necessary to address this issue.Binder:2632_6: page allocation failure: order:4, mode:0x6040c0(GFP_KERNEL|__GFP_COMP), nodemask=(null)Call trace:[242178.097582] dump_backtrace+0x0/0x4[242178.097589] dump_stack+0xf4/0x134[242178.097598] warn_alloc+0xd8/0x144[242178.097603] __alloc_pages_nodemask+0x1364/0x1384[242178.097608] kmalloc_order+0x2c/0x510[242178.097612] kmalloc_order_trace+0x40/0x16c[242178.097618] __kmalloc+0x360/0x408[242178.097624] load_alloc_bitmap+0x160/0x284[242178.097628] exfat_fill_super+0xa3c/0xe7c[242178.097635] mount_bdev+0x2e8/0x3a0[242178.097638] exfat_fs_mount+0x40/0x50[242178.097643] mount_fs+0x138/0x2e8[242178.097649] vfs_kern_mount+0x90/0x270[242178.097655] do_mount+0x798/0x173c[242178.097659] ksys_mount+0x114/0x1ac[242178.097665] __arm64_sys_mount+0x24/0x34[242178.097671] el0_svc_common+0xb8/0x1b8[242178.097676] el0_svc_handler+0x74/0x90[242178.097681] el0_svc+0x8/0x340By analyzing the exfat code,we found that continuous physical memoryis not required here,so kvmalloc_array is used can solve this problem.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54282 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: tuners: qt1010: replace BUG_ON with a regular errorBUG_ON is unnecessary here, and in addition it confuses smatch.Replacing this with an error return help resolve this smatchwarning:drivers/media/tuners/qt1010.c:350 qt1010_init() error: buffer overflow 'i2c_data' 34 <= 34

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0340 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in vhost_new_msg in drivers/vhost/vhost.c in the Linux kernel, which does not properly initialize memory in messages passed between virtual guests and the host operating system in the vhost/vhost.c:vhost_new_msg() function. This issue can allow local privileged users to read some kernel memory contents when reading from the /dev/vhost-net device file.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-0727 Severity: Low CVSS3 score: 3.3

Description: Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe vulnerable to this issue.OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()and PKCS12_newpass().We have also fixed a similar issue in SMIME_write_PKCS7(). However since thisfunction is related to writing data we do not consider it security significant.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
libopenssl1_1 > 0-0 (version in image is 1.1.1l-150400.7.84.1).

CVE-2024-26597 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: qualcomm: rmnet: fix global oob in rmnet_policyThe variable rmnet_link_ops assign a *bigger* maxtype which leads to aglobal out-of-bounds read when parsing the netlink attributes. See bugtrace below:==================================================================BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7fdcf2072359Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 The buggy address belongs to the variable: rmnet_policy+0x30/0xe0The buggy address belongs to the physical page:page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243flags: 0x200000000001000(reserved|node=0|zone=2)raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9According to the comment of `nla_parse_nested_deprecated`, the maxtypeshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26835 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: set dormant flag on hook register failureWe need to set the dormant flag again if we fail to registerthe hooks.During memory pressure hook registration can fail and we end upwith a table marked as active but no registered hooks.On table/base chain deletion, nf_tables will attempt to unregisterthe hook again which yields a warn splat from the nftables core.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26837 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: switchdev: Skip MDB replays of deferred events on offloadBefore this change, generation of the list of MDB events to replaywould race against the creation of new group memberships, either fromthe IGMP/MLD snooping logic or from user configuration.While new memberships are immediately visible to walkers ofbr->mdb_list, the notification of their existence to switchdev eventsubscribers is deferred until a later point in time. So if a replaylist was generated during a time that overlapped with such a window,it would also contain a replay of the not-yet-delivered event.The driver would thus receive two copies of what the bridge internallyconsidered to be one single event. On destruction of the bridge, onlya single membership deletion event was therefore sent. As aconsequence of this, drivers which reference count memberships (atleast DSA), would be left with orphan groups in their hardwaredatabase when the bridge was destroyed.This is only an issue when replaying additions. While deletion eventsmay still be pending on the deferred queue, they will already havebeen removed from br->mdb_list, so no duplicates can be generated inthat scenario.To a user this meant that old group memberships, from a bridge inwhich a port was previously attached, could be reanimated (inhardware) when the port joined a new bridge, without the new bridge'sknowledge.For example, on an mv88e6xxx system, create a snooping bridge andimmediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$The two IPv6 groups remain in the hardware database because theport (x3) is notified of the host's membership twice: once via theoriginal event and once via a replay. Since only a single deletenotification is sent, the count remains at 1 when the bridge isdestroyed.Then add the same port (or another port belonging to the same hardwaredomain) to a new bridge, this time with snooping disabled: root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \ > ip link set dev x3 up master br1All multicast, including the two IPv6 groups from br0, should now beflooded, according to the policy of br1. But instead the oldmemberships are still active in the hardware database, causing theswitch to only forward traffic to those groups towards the CPU (port0).Eliminate the race in two steps:1. Grab the write-side lock of the MDB while generating the replay list.This prevents new memberships from showing up while we are generatingthe replay list. But it leaves the scenario in which a deferred eventwas already generated, but not delivered, before we grabbed thelock. Therefore:2. Make sure that no deferred version of a replay event is already enqueued to the switchdev deferred queue, before adding it to the replay list, when replaying additions.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26839 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix a memleak in init_credit_returnWhen dma_alloc_coherent fails to allocate dd->cr_base[i].va,init_credit_return should deallocate dd->cr_base anddd->cr_base[i] that allocated before. Or those resourceswould be never freed and a memleak is triggered.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-34459 Severity: Low CVSS3 score: 3.3

Description: An issue was discovered in xmllint (from libxml2) before 2.11.8 and 2.12.x before 2.12.7. Formatting error messages with xmllint --htmlout can result in a buffer over-read in xmlHTMLPrintFileContext in xmllint.c.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2024-36955 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()The documentation for device_get_named_child_node() mentions thisimportant point:"The caller is responsible for calling fwnode_handle_put() on thereturned fwnode pointer."Add fwnode_handle_put() to avoid a leaked reference.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-40981 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:batman-adv: bypass empty buckets in batadv_purge_orig_ref()Many syzbot reports are pointing to soft lockups inbatadv_purge_orig_ref() [1]Root cause is unknown, but we can avoid spending too muchtime there and perhaps get more interesting reports.[1]watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]Modules linked in:irq event stamp: 6182794 hardirqs last enabled at (6182793): [] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386 hardirqs last disabled at (6182794): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (6182794): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (6182792): [] spin_unlock_bh include/linux/spinlock.h:396 [inline] softirqs last enabled at (6182792): [] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 softirqs last disabled at (6182790): [] spin_lock_bh include/linux/spinlock.h:356 [inline] softirqs last disabled at (6182790): [] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024Workqueue: bat_events batadv_purge_origpstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline] pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386sp : ffff800099007970x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000Call trace: __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline] arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline] __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287 batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300 process_one_work+0x694/0x1204 kernel/workqueue.c:2633 process_scheduled_works kernel/workqueue.c:2706 [inline] worker_thread+0x938/0xef4 kernel/workqueue.c:2787 kthread+0x288/0x310 kernel/kthread.c:388 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860Sending NMI from CPU 0 to CPUs 1:NMI backtrace for cpu 1CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103sp : ffff800093a17d30x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-49895 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translationThis commit addresses a potential index out of bounds issue in the`cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30color management module. The issue could occur when the index 'i'exceeds the number of transfer function points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure 'i' is within bounds before accessing thetransfer function points. If 'i' is out of bounds, the function returnsfalse to indicate an error.Reported by smatch:drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53079 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm/thp: fix deferred split unqueue naming and lockingRecent changes are putting more pressure on THP deferred split queues:under load revealing long-standing races, causing list_del corruptions,"Bad page state"s and worse (I keep BUGs in both of those, so usuallydon't get to see how badly they end up without). The relevant recentchanges being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin,improved swap allocation, and underused THP splitting.Before fixing locking: rename misleading folio_undo_large_rmappable(),which does not undo large_rmappable, to folio_unqueue_deferred_split(),which is what it does. But that and its out-of-line __callee are mminternals of very limited usability: add comment and WARN_ON_ONCEs tocheck usage; and return a bool to say if a deferred split was unqueued,which can then be used in WARN_ON_ONCEs around safety checks (sparingcallers the arcane conditionals in __folio_unqueue_deferred_split()).Just omit the folio_unqueue_deferred_split() from free_unref_folios(), allof whose callers now call it beforehand (and if any forget then bad_page()will tell) - except for its caller put_pages_list(), which itself nolonger has any callers (and will be deleted separately).Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0without checking and unqueueing a THP folio from deferred split list;which is unfortunate, since the split_queue_lock depends on the memcg(when memcg is enabled); so swapout has been unqueueing such THPs later,when freeing the folio, using the pgdat's lock instead: potentiallycorrupting the memcg's list. __remove_mapping() has frozen refcount to 0here, so no problem with calling folio_unqueue_deferred_split() beforeresetting memcg_data.That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred splitshrinker memcg aware"): which included a check on swapcache before addingto deferred queue, but no check on deferred queue before adding THP toswapcache. That worked fine with the usual sequence of events in reclaim(though there were a couple of rare ways in which a THP on deferred queuecould have been swapped out), but 6.12 commit dafff3f4c850 ("mm: splitunderused THPs") avoids splitting underused THPs in reclaim, which makesswapcache THPs on deferred queue commonplace.Keep the check on swapcache before adding to deferred queue? Yes: it isno longer essential, but preserves the existing behaviour, and is likelyto be a worthwhile optimization (vmstat showed much more traffic on thequeue under swapping load if the check was removed); update its comment.Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changingfolio->memcg_data without checking and unqueueing a THP folio from thedeferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only beused in a WARN_ON_ONCE to validate the fix, which must be done earlier:mem_cgroup_move_charge_pte_range() first try to split the THP (splittingof course unqueues), or skip it if that fails. Not ideal, but movingcharge has been requested, and khugepaged should repair the THP later:nobody wants new custom unqueueing code just for this deprecated case.The 87eaceb3faa5 commit did have the code to move from one deferred listto another (but was not conscious of its unsafety while refcount non-0);but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need caredeferred split queue in memcg charge move path"), which argued that theexistence of a PMD mapping guarantees that the THP cannot be on a deferredlist. As above, false in rare cases, and now commonly false.Backport to 6.11 should be straightforward. Earlier backports must takecare that other _deferred_list fixes and dependencies are included. Thereis not a strong case for backports, but they can fix cornercases.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56531 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: caiaq: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.This patch also splits the code to the disconnect and the free phases;the former is called immediately at the USB disconnect callback whilethe latter is called from the card destructor.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56532 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: us122l: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.The loop of us122l->mmap_count check is dropped as well. The check isuseless for the asynchronous operation with *_when_closed().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56533 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usx2y: Use snd_card_free_when_closed() at disconnectionThe USB disconnect callback is supposed to be short and not too-longwaiting. OTOH, the current code uses snd_card_free() atdisconnection, but this waits for the close of all used fds, hence itcan take long. It eventually blocks the upper layer USB ioctls, whichmay trigger a soft lockup.An easy workaround is to replace snd_card_free() withsnd_card_free_when_closed(). This variant returns immediately whilethe release of resources is done asynchronously by the card devicerelease at the last close.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56572 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: platform: allegro-dvt: Fix possible memory leak in allocate_buffers_internal()The buffer in the loop should be released under the exception path,otherwise there may be a memory leak here.To mitigate this, free the buffer when allegro_alloc_buffer fails.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56643 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:dccp: Fix memory leak in dccp_feat_change_recvIf dccp_feat_push_confirm() fails after new value for SP feature was acceptedwithout reconciliation ('entry == NULL' branch), memory allocated for that valuewith dccp_feat_clone_sp_val() is never freed.Here is the kmemleak stack for this:unreferenced object 0xffff88801d4ab488 (size 8): comm "syz-executor310", pid 1127, jiffies 4295085598 (age 41.666s) hex dump (first 8 bytes): 01 b4 4a 1d 80 88 ff ff ..J..... backtrace: [<00000000db7cabfe>] kmemdup+0x23/0x50 mm/util.c:128 [<0000000019b38405>] kmemdup include/linux/string.h:465 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:371 [inline] [<0000000019b38405>] dccp_feat_clone_sp_val net/dccp/feat.c:367 [inline] [<0000000019b38405>] dccp_feat_change_recv net/dccp/feat.c:1145 [inline] [<0000000019b38405>] dccp_feat_parse_options+0x1196/0x2180 net/dccp/feat.c:1416 [<00000000b1f6d94a>] dccp_parse_options+0xa2a/0x1260 net/dccp/options.c:125 [<0000000030d7b621>] dccp_rcv_state_process+0x197/0x13d0 net/dccp/input.c:650 [<000000001f74c72e>] dccp_v4_do_rcv+0xf9/0x1a0 net/dccp/ipv4.c:688 [<00000000a6c24128>] sk_backlog_rcv include/net/sock.h:1041 [inline] [<00000000a6c24128>] __release_sock+0x139/0x3b0 net/core/sock.c:2570 [<00000000cf1f3a53>] release_sock+0x54/0x1b0 net/core/sock.c:3111 [<000000008422fa23>] inet_wait_for_connect net/ipv4/af_inet.c:603 [inline] [<000000008422fa23>] __inet_stream_connect+0x5d0/0xf70 net/ipv4/af_inet.c:696 [<0000000015b6f64d>] inet_stream_connect+0x53/0xa0 net/ipv4/af_inet.c:735 [<0000000010122488>] __sys_connect_file+0x15c/0x1a0 net/socket.c:1865 [<00000000b4b70023>] __sys_connect+0x165/0x1a0 net/socket.c:1882 [<00000000f4cb3815>] __do_sys_connect net/socket.c:1892 [inline] [<00000000f4cb3815>] __se_sys_connect net/socket.c:1889 [inline] [<00000000f4cb3815>] __x64_sys_connect+0x6e/0xb0 net/socket.c:1889 [<00000000e7b1e839>] do_syscall_64+0x33/0x40 arch/x86/entry/common.c:46 [<0000000055e91434>] entry_SYSCALL_64_after_hwframe+0x67/0xd1Clean up the allocated memory in case of dccp_feat_push_confirm() failureand bail out with an error reset code.Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56741 Severity: Low CVSS3 score: 3.3

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57872 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()This will ensure that the scsi host is cleaned up properly usingscsi_host_dev_release(). Otherwise, it may lead to memory leaks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57874 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRLCurrently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'variable, and a SETREGSET call with a length of zero will leave thisuninitialized. Consequently tagged_addr_ctrl_set() will consume anarbitrary value, potentially leaking up to 64 bits of memory from thekernel stack. The read is limited to a specific slot on the stack, andthe issue does not provide a write mechanism.As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero andrejects other values, a partial SETREGSET attempt will randomly succeedor fail depending on the value of the uninitialized value, and theexposure is significantly limited.Fix this by initializing the temporary value before copying the regsetfrom userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existingvalue of the tagged address ctrl will be retained.The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in theuser_aarch64_view used by a native AArch64 task to manipulate anothernative AArch64 task. As get_tagged_addr_ctrl() only returns an errorvalue when called for a compat task, tagged_addr_ctrl_get() andtagged_addr_ctrl_set() should never observe an error value fromget_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate thatsuch an error would be unexpected, and error handlnig is not missing ineither case.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57907 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: rockchip_saradc: fix information leak in triggered bufferThe 'data' local struct is used to push data to user space from atriggered buffer, but it does not set values for inactive channels, asit only uses iio_for_each_active_channel() to assign new values.Initialize the struct to zero before using it to avoid pushinguninitialized information to userspace.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58001 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:ocfs2: handle a symlink read error correctlyPatch series "Convert ocfs2 to use folios".Mark did a conversion of ocfs2 to use folios and sent it to me as agiant patch for review ;-)So I've redone it as individual patches, and credited Mark for the patcheswhere his code is substantially the same. It's not a bad way to do it;his patch had some bugs and my patches had some bugs. Hopefully all ourbugs were different from each other. And hopefully Mark likes all thechanges I made to his code!This patch (of 23):If we can't read the buffer, be sure to unlock the page before returning.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-58251 Severity: Low CVSS3 score: 3.3

Description: In netstat in BusyBox through 1.37.0, local users can launch of network application with an argv[0] containing an ANSI terminal escape sequence, leading to a denial of service (terminal locked up) when netstat is used by a victim.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
iproute2 > 0-0 (version in image is 5.14-150400.3.3.1).

CVE-2025-11494 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in GNU Binutils 2.45. Impacted is the function _bfd_x86_elf_late_size_sections of the file bfd/elfxx-x86.c of the component Linker. The manipulation results in out-of-bounds read. The attack needs to be approached locally. The exploit has been made public and could be used. The patch is identified as b6ac5a8a5b82f0ae6a4642c8d7149b325f4cc60a. A patch should be applied to remediate this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-11495 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was determined in GNU Binutils 2.45. The affected element is the function elf_x86_64_relocate_section of the file elf64-x86-64.c of the component Linker. This manipulation causes heap-based buffer overflow. The attack can only be executed locally. The exploit has been publicly disclosed and may be utilized. Patch name: 6b21c8b2ecfef5c95142cbc2c32f185cb1c26ab0. To fix this issue, it is recommended to deploy a patch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-11839 Severity: Low CVSS3 score: 3.3

Description: A security flaw has been discovered in GNU Binutils 2.45. Impacted is the function tg_tag_type of the file prdbg.c. Performing manipulation results in unchecked return value. The attack needs to be approached locally. The exploit has been released to the public and may be exploited.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-11840 Severity: Low CVSS3 score: 3.3

Description: A weakness has been identified in GNU Binutils 2.45. The affected element is the function vfinfo of the file ldmisc.c. Executing manipulation can lead to out-of-bounds read. The attack can only be executed locally. The exploit has been made available to the public and could be exploited. This patch is called 16357. It is best practice to apply a patch to resolve this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-11961 Severity: Low CVSS3 score: 3.3

Description: pcap_ether_aton() is an auxiliary function in libpcap, it takes a string argument and returns a fixed-size allocated buffer. The string argument must be a well-formed MAC-48 address in one of the supported formats, but this requirement has been poorly documented. If an application calls the function with an argument that deviates from the expected format, the function can read data beyond the end of the provided string and write data beyond the end of the allocated buffer.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpcap1 > 0-0 (version in image is 1.10.1-150400.3.6.2).

CVE-2025-21656 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:hwmon: (drivetemp) Fix driver producing garbage data when SCSI errors occurscsi_execute_cmd() function can return both negative (linux codes) andpositive (scsi_cmnd result field) error codes.Currently the driver just passes error codes of scsi_execute_cmd() tohwmon core, which is incorrect because hwmon only checks for negativeerror codes. This leads to hwmon reporting uninitialized data touserspace in case of SCSI errors (for example if the disk drive wasdisconnected).This patch checks scsi_execute_cmd() output and returns -EIO if it'serror code is positive.[groeck: Avoid inline variable declaration for portability]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21697 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/v3d: Ensure job pointer is set to NULL after job completionAfter a job completes, the corresponding pointer in the device mustbe set to NULL. Failing to do so triggers a warning when unloadingthe driver, as it appears the job is still active. To prevent this,assign the job pointer to NULL after completing the job, indicatingthe job has finished.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-21749 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: rose: lock the socket in rose_bind()syzbot reported a soft lockup in rose_loopback_timer(),with a repro calling bind() from multiple threads.rose_bind() must lock the socket to avoid this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-2588 Severity: Low CVSS3 score: 3.3

Description: A vulnerability has been found in Hercules Augeas 1.14.1 and classified as problematic. This vulnerability affects the function re_case_expand of the file src/fa.c. The manipulation of the argument re leads to null pointer dereference. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
augeas > 0-0 (version in image is 1.12.0-150400.3.8.1).

CVE-2025-37998 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:openvswitch: Fix unsafe attribute parsing in output_userspace()This patch replaces the manual Netlink attribute iteration inoutput_userspace() with nla_for_each_nested(), which ensures that onlywell-formed attributes are processed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38009 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: disable napi on driver removalA warning on driver removal started occurring after commit 9dd05df8403b("net: warn if NAPI instance wasn't shut down"). Disable tx napi beforedeleting it in mt76_dma_cleanup(). WARNING: CPU: 4 PID: 18828 at net/core/dev.c:7288 __netif_napi_del_locked+0xf0/0x100 CPU: 4 UID: 0 PID: 18828 Comm: modprobe Not tainted 6.15.0-rc4 #4 PREEMPT(lazy) Hardware name: ASUS System Product Name/PRIME X670E-PRO WIFI, BIOS 3035 09/05/2024 RIP: 0010:__netif_napi_del_locked+0xf0/0x100 Call Trace: mt76_dma_cleanup+0x54/0x2f0 [mt76] mt7921_pci_remove+0xd5/0x190 [mt7921e] pci_device_remove+0x47/0xc0 device_release_driver_internal+0x19e/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x6d/0xf0 pci_unregister_driver+0x2e/0xb0 __do_sys_delete_module.isra.0+0x197/0x2e0 do_syscall_64+0x7b/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7eTested with mt7921e but the same pattern can be actually applied to othermt76 drivers calling mt76_dma_cleanup() during removal. Tx napi is enabledin their *_dma_init() functions and only toggled off and on again insidetheir suspend/resume/reset paths. So it should be okay to disable txnapi in such a generic way.Found by Linux Verification Center (linuxtesting.org).

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38384 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: spinand: fix memory leak of ECC engine confMemory allocated for the ECC engine conf is not released during spinandcleanup. Below kmemleak trace is seen for this memory leak:unreferenced object 0xffffff80064f00e0 (size 8): comm "swapper/0", pid 1, jiffies 4294937458 hex dump (first 8 bytes): 00 00 00 00 00 00 00 00 ........ backtrace (crc 0): kmemleak_alloc+0x30/0x40 __kmalloc_cache_noprof+0x208/0x3c0 spinand_ondie_ecc_init_ctx+0x114/0x200 nand_ecc_init_ctx+0x70/0xa8 nanddev_ecc_engine_init+0xec/0x27c spinand_probe+0xa2c/0x1620 spi_mem_probe+0x130/0x21c spi_probe+0xf0/0x170 really_probe+0x17c/0x6e8 __driver_probe_device+0x17c/0x21c driver_probe_device+0x58/0x180 __device_attach_driver+0x15c/0x1f8 bus_for_each_drv+0xec/0x150 __device_attach+0x188/0x24c device_initial_probe+0x10/0x20 bus_probe_device+0x11c/0x160Fix the leak by calling nanddev_ecc_engine_cleanup() insidespinand_cleanup().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38409 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm: Fix another leak in the submit error pathput_unused_fd() doesn't free the installed file, if we've already donefd_install(). So we need to also free the sync_file.Patchwork: https://patchwork.freedesktop.org/patch/653583/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38439 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Set DMA unmap len correctly for XDP_REDIRECTWhen transmitting an XDP_REDIRECT packet, call dma_unmap_len_set()with the proper length instead of 0. This bug triggers this warningon a system with IOMMU enabled:WARNING: CPU: 36 PID: 0 at drivers/iommu/dma-iommu.c:842 __iommu_dma_unmap+0x159/0x170RIP: 0010:__iommu_dma_unmap+0x159/0x170Code: a8 00 00 00 00 48 c7 45 b0 00 00 00 00 48 c7 45 c8 00 00 00 00 48 c7 45 a0 ff ff ff ff 4c 89 45b8 4c 89 45 c0 e9 77 ff ff ff <0f> 0b e9 60 ff ff ff e8 8b bf 6a 00 66 66 2e 0f 1f 84 00 00 00 00RSP: 0018:ff22d31181150c88 EFLAGS: 00010206RAX: 0000000000002000 RBX: 00000000e13a0000 RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ff22d31181150cf0 R08: ff22d31181150ca8 R09: 0000000000000000R10: 0000000000000000 R11: ff22d311d36c9d80 R12: 0000000000001000R13: ff13544d10645010 R14: ff22d31181150c90 R15: ff13544d0b2bac00FS: 0000000000000000(0000) GS:ff13550908a00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005be909dacff8 CR3: 0008000173408003 CR4: 0000000000f71ef0PKRU: 55555554Call Trace:? show_regs+0x6d/0x80? __warn+0x89/0x160? __iommu_dma_unmap+0x159/0x170? report_bug+0x17e/0x1b0? handle_bug+0x46/0x90? exc_invalid_op+0x18/0x80? asm_exc_invalid_op+0x1b/0x20? __iommu_dma_unmap+0x159/0x170? __iommu_dma_unmap+0xb3/0x170iommu_dma_unmap_page+0x4f/0x100dma_unmap_page_attrs+0x52/0x220? srso_alias_return_thunk+0x5/0xfbef5? xdp_return_frame+0x2e/0xd0bnxt_tx_int_xdp+0xdf/0x440 [bnxt_en]__bnxt_poll_work_done+0x81/0x1e0 [bnxt_en]bnxt_poll+0xd3/0x1e0 [bnxt_en]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38481 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: Fail COMEDI_INSNLIST ioctl if n_insns is too largeThe handling of the `COMEDI_INSNLIST` ioctl allocates a kernel buffer tohold the array of `struct comedi_insn`, getting the length from the`n_insns` member of the `struct comedi_insnlist` supplied by the user.The allocation will fail with a WARNING and a stack dump if it is toolarge.Avoid that by failing with an `-EINVAL` error if the supplied `n_insns`value is unreasonable.Define the limit on the `n_insns` value in the `MAX_INSNS` macro. Setthis to the same value as `MAX_SAMPLES` (65536), which is the maximumallowed sum of the values of the member `n` in the array of `structcomedi_insn`, and sensible comedi instructions will have an `n` of atleast 1.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38565 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:perf/core: Exit early on perf_mmap() failWhen perf_mmap() fails to allocate a buffer, it still invokes theevent_mapped() callback of the related event. On X86 this might increasethe perf_rdpmc_allowed reference counter. But nothing undoes this asperf_mmap_close() is never called in this case, which causes anotherreference count leak.Return early on failure to prevent that.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38623 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: pnv_php: Fix surprise plug detection and recoveryThe existing PowerNV hotplug code did not handle surprise plug eventscorrectly, leading to a complete failure of the hotplug system after deviceremoval and a required reboot to detect new devices.This comes down to two issues: 1) When a device is surprise removed, often the bridge upstream port will cause a PE freeze on the PHB. If this freeze is not cleared, the MSI interrupts from the bridge hotplug notification logic will not be received by the kernel, stalling all plug events on all slots associated with the PE. 2) When a device is removed from a slot, regardless of surprise or programmatic removal, the associated PHB/PE ls left frozen. If this freeze is not cleared via a fundamental reset, skiboot is unable to clear the freeze and cannot retrain / rescan the slot. This also requires a reboot to clear the freeze and redetect the device in the slot.Issue the appropriate unfreeze and rescan commands on hotplug events,and don't oops on hotplug if pci_bus_to_OF_node() returns NULL.[bhelgaas: tidy comments]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39957 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: increase scan_ies_len for S1GCurrently the S1G capability element is not taken into accountfor the scan_ies_len, which leads to a buffer length validationfailure in ieee80211_prep_hw_scan() and subsequent WARN in__ieee80211_start_scan(). This prevents hw scanning from functioning.To fix ensure we accommodate for the S1G capability length.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39968 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:i40e: add max boundary check for VF filtersThere is no check for max filters that VF can request. Add it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40103 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: Fix refcount leak for cifs_sb_tlinkFix three refcount inconsistency issues related to `cifs_sb_tlink`.Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to becalled after successful calls to `cifs_sb_tlink()`. Three calls fail toupdate refcount accordingly, leading to possible resource leaks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40105 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:vfs: Don't leak disconnected dentries on umountWhen user calls open_by_handle_at() on some inode that is not cached, wewill create disconnected dentry for it. If such dentry is a directory,exportfs_decode_fh_raw() will then try to connect this dentry to thedentry tree through reconnect_path(). It may happen for various reasons(such as corrupted fs or race with rename) that the call tolookup_one_unlocked() in reconnect_one() will fail to find the dentry weare trying to reconnect and instead create a new dentry under theparent. Now this dentry will not be marked as disconnected although theparent still may well be disconnected (at least in case thisinconsistency happened because the fs is corrupted and .. doesn't pointto the real parent directory). This creates inconsistency indisconnected flags but AFAICS it was mostly harmless. At least untilcommit f1ee616214cb ("VFS: don't keep disconnected dentries on d_anon")which removed adding of most disconnected dentries to sb->s_anon list.Thus after this commit cleanup of disconnected dentries implicitelyrelies on the fact that dput() will immediately reclaim such dentries.However when some leaf dentry isn't marked as disconnected, as in thescenario described above, the reclaim doesn't happen and the dentriesare "leaked". Memory reclaim can eventually reclaim them but otherwisethey stay in memory and if umount comes first, we hit infamous "Busyinodes after unmount" bug. Make sure all dentries created under adisconnected parent are marked as disconnected as well.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40140 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: Remove disruptive netif_wake_queue in rtl8150_set_multicastsyzbot reported WARNING in rtl8150_start_xmit/usb_submit_urb.This is the sequence of events that leads to the warning:rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb);}rtl8150_set_multicast() { netif_stop_queue(); netif_wake_queue(); <-- wakes up TX queue before URB is done}rtl8150_start_xmit() { netif_stop_queue(); usb_submit_urb(dev->tx_urb); <-- double submission}rtl8150_set_multicast being the ndo_set_rx_mode callback should not becalling netif_stop_queue and notif_start_queue as these handleTX queue synchronization.The net core function dev_set_rx_mode handles the synchronizationfor rtl8150_set_multicast making it safe to remove these locks.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40153 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:mm: hugetlb: avoid soft lockup when mprotect to large memory areaWhen calling mprotect() to a large hugetlb memory area in our customer'sworkload (~300GB hugetlb memory), soft lockup was observed:watchdog: BUG: soft lockup - CPU#98 stuck for 23s! [t2_new_sysv:126916]CPU: 98 PID: 126916 Comm: t2_new_sysv Kdump: loaded Not tainted 6.17-rc7Hardware name: GIGACOMPUTING R2A3-T40-AAV1/Jefferson CIO, BIOS 5.4.4.1 07/15/2025pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : mte_clear_page_tags+0x14/0x24lr : mte_sync_tags+0x1c0/0x240sp : ffff80003150bb80x29: ffff80003150bb80 x28: ffff00739e9705a8 x27: 0000ffd2d6a00000x26: 0000ff8e4bc00000 x25: 00e80046cde00f45 x24: 0000000000022458x23: 0000000000000000 x22: 0000000000000004 x21: 000000011b380000x20: ffff000000000000 x19: 000000011b379f40 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc875e0aa5e2cx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffc01ce7a5c00 x4 : 00000000046cde00 x3 : fffffc0000000000x2 : 0000000000000004 x1 : 0000000000000040 x0 : ffff0046cde7c000Call trace: mte_clear_page_tags+0x14/0x24 set_huge_pte_at+0x25c/0x280 hugetlb_change_protection+0x220/0x430 change_protection+0x5c/0x8c mprotect_fixup+0x10c/0x294 do_mprotect_pkey.constprop.0+0x2e0/0x3d4 __arm64_sys_mprotect+0x24/0x44 invoke_syscall+0x50/0x160 el0_svc_common+0x48/0x144 do_el0_svc+0x30/0xe0 el0_svc+0x30/0xf0 el0t_64_sync_handler+0xc4/0x148 el0t_64_sync+0x1a4/0x1a8Soft lockup is not triggered with THP or base page because there iscond_resched() called for each PMD size.Although the soft lockup was triggered by MTE, it should be not MTEspecific. The other processing which takes long time in the loop maytrigger soft lockup too.So add cond_resched() for hugetlb to avoid soft lockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40160 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:xen/events: Return -EEXIST for bound VIRQsChange find_virq() to return -EEXIST when a VIRQ is bound to adifferent CPU than the one passed in. With that, remove the BUG_ON()from bind_virq_to_irq() to propogate the error upwards.Some VIRQs are per-cpu, but others are per-domain or global. Those mustbe bound to CPU0 and can then migrate elsewhere. The lookup forper-domain and global will probably fail when migrated off CPU 0,especially when the current CPU is tracked. This now returns -EEXISTinstead of BUG_ON().A second call to bind a per-domain or global VIRQ is not expected, butmake it non-fatal to avoid trying to look up the irq, since we don'tknow which per_cpu(virq_to_irq) it will be in.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71094 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:net: usb: asix: validate PHY address before useThe ASIX driver reads the PHY address from the USB device viaasix_read_phy_addr(). A malicious or faulty device can return aninvalid address (>= PHY_MAX_ADDR), which causes a warning inmdiobus_get_phy(): addr 207 out of range WARNING: drivers/net/phy/mdio_bus.c:76Validate the PHY address in asix_read_phy_addr() and remove thenow-redundant check in ax88172a.c.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-71125 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Do not register unsupported perf eventsSynthetic events currently do not have a function to register perf events.This leads to calling the tracepoint register functions with a NULLfunction pointer which triggers: ------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepoint_add_func+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvm_intel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepoint_add_func+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: tracepoint_probe_register+0x5d/0x90 synth_event_reg+0x3c/0x60 perf_trace_event_init+0x204/0x340 perf_trace_init+0x85/0xd0 perf_tp_event_init+0x2e/0x50 perf_try_init_event+0x6f/0x230 ? perf_event_alloc+0x4bb/0xdc0 perf_event_alloc+0x65a/0xdc0 __se_sys_perf_event_open+0x290/0x9f0 do_syscall_64+0x93/0x7b0 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e ? trace_hardirqs_off+0x53/0xc0 entry_SYSCALL_64_after_hwframe+0x76/0x7eInstead, have the code return -ENODEV, which doesn't warn and has perferror out with: # perf record -e synthetic:futex_waitError:The sys_perf_event_open() syscall returned with 19 (No such device) for event (synthetic:futex_wait)."dmesg | grep -i perf" may provide additional information.Ideally perf should support synthetic events, but for now just fix thewarning. The support can come later.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-8224 Severity: Low CVSS3 score: 3.3

Description: A vulnerability has been found in GNU Binutils 2.44 and classified as problematic. This vulnerability affects the function bfd_elf_get_str_section of the file bfd/elf.c of the component BFD Library. The manipulation leads to null pointer dereference. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The name of the patch is db856d41004301b3a56438efd957ef5cabb91530. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-8225 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in GNU Binutils 2.44 and classified as problematic. This issue affects the function process_debug_info of the file binutils/dwarf.c of the component DWARF Section Handler. The manipulation leads to memory leak. Attacking locally is a requirement. The identifier of the patch is e51fdff7d2e538c0e5accdd65649ac68e6e0ddd4. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-8291 Severity: Low CVSS3 score: 3.3

Description: The 'zipfile' module would not check the validity of the ZIP64 End ofCentral Directory (EOCD) Locator record offset value would not be used tolocate the ZIP64 EOCD record, instead the ZIP64 EOCD record would beassumed to be the previous record in the ZIP archive. This could be abusedto create ZIP archives that are handled differently by the 'zipfile' modulecompared to other ZIP implementations.Remediation maintains this behavior, but checks that the offset specifiedin the ZIP64 EOCD Locator record matches the expected value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpython3_11-1_0 < 3.11.14-150400.9.69.1 (version in image is 3.11.13-150400.9.66.1).

CVE-2025-8732 Severity: Low CVSS3 score: 3.3

Description: A vulnerability was found in libxml2 up to 2.14.5. It has been declared as problematic. This vulnerability affects the function xmlParseSGMLCatalog of the component xmlcatalog. The manipulation leads to uncontrolled recursion. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The real existence of this vulnerability is still doubted at the moment. The code maintainer explains, that "[t]he issue can only be triggered with untrusted SGML catalogs and it makes absolutely no sense to use untrusted catalogs. I also doubt that anyone is still using SGML catalogs at all."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gettext-runtime > 0-0 (version in image is 0.20.2-1.43).

CVE-2025-15224 Severity: Moderate CVSS3 score: 3.1

Description: When doing SSH-based transfers using either SCP or SFTP, and asked to dopublic key authentication, curl would wrongly still ask and authenticate usinga locally running SSH agent.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
curl > 0-0 (version in image is 8.14.1-150400.5.69.1).

CVE-2025-1795 Severity: Low CVSS3 score: 3.1

Description: During an address list folding when a separating comma ends up on a folded line and that line is to be unicode-encoded then the separator itself is also unicode-encoded. Expected behavior is that the separating comma remains a plan comma. This can result in the address header being misinterpreted by some mail servers.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
python311 > 0-0 (version in image is 3.11.13-150400.9.66.2).

CVE-2025-8277 Severity: Low CVSS3 score: 3.1

Description: A flaw was found in libssh's handling of key exchange (KEX) processes when a client repeatedly sends incorrect KEX guesses. The library fails to free memory during these rekey operations, which can gradually exhaust system memory. This issue can lead to crashes on the client side, particularly when using libgcrypt, which impacts application stability and availability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libssh-config > 0-0 (version in image is 0.9.8-150400.3.9.1).

CVE-2020-12965 Severity: Low CVSS3 score: 2.9

Description: When combined with specific software sequences, AMD CPUs may transiently execute non-canonical loads and store using only the lower 48 address bits potentially resulting in data leakage.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-32415 Severity: Low CVSS3 score: 2.9

Description: In libxml2 before 2.13.8 and 2.14.x before 2.14.2, xmlSchemaIDCFillNodeTables in xmlschemas.c has a heap-based buffer under-read. To exploit this, a crafted XML document must be validated against an XML schema with certain identity constraints, or a crafted XML schema must be used.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libxml2-2 > 0-0 (version in image is 2.9.14-150400.5.47.1).

CVE-2025-58767 Severity: Low CVSS3 score: 2.9

Description: REXML is an XML toolkit for Ruby. The REXML gems from 3.3.3 to 3.4.1 has a DoS vulnerability when parsing XML containing multiple XML declarations. If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities. The REXML gem 3.4.2 or later include the patches to fix these vulnerabilities.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150000.4.49.1).

CVE-2024-42097 Severity: Moderate CVSS3 score: 2.8

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: emux: improve patch ioctl data validationIn load_data(), make the validation of and skipping over the main infoblock match that in load_guspatch().In load_guspatch(), add checking that the specified patch length matchesthe actually supplied data, like load_data() already did.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-48233 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. If the count after the :s command is larger than what fits into a (signed) long variable, abort with e_value_too_large. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `ac6378773` which has been included in release version 9.0.2108. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-48234 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When getting the count for a normal mode z command, it may overflow for large counts given. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `58f9befca1` which has been included in release version 9.0.2109. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-48235 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause anoverflow. Ironically this happens in the existing overflow check, because the line number becomes negative and LONG_MAX - lnum will cause the overflow. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `060623e` which has been included in release version 9.0.2110. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-48236 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values largerthan MAX_INT. Impact is low, user interaction is required and a crash may not even happen in all situations. This vulnerability has been addressed in commit `73b2d379` which has been included in release version 9.0.2111. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2023-48237 Severity: Low CVSS3 score: 2.8

Description: Vim is an open source command line text editor. In affected versions when shifting lines in operator pending mode and using a very large value, it may be possible to overflow the size of integer. Impact is low, user interaction is required and a crash may not even happen in all situations. This issue has been addressed in commit `6bf131888` which has been included in version 9.0.2112. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Packages affected:

sle-module-basesystem-release == 15.4 (version in image is 15.4-150400.55.1).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-1215 Severity: Low CVSS3 score: 2.8

Description: A vulnerability classified as problematic was found in vim up to 9.1.1096. This vulnerability affects unknown code of the file src/main.c. The manipulation of the argument --log leads to memory corruption. It is possible to launch the attack on the local host. Upgrading to version 9.1.1097 is able to address this issue. The patch is identified as c5654b84480822817bb7b69ebc97c174c91185e9. It is recommended to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
vim > 0-0 (version in image is 9.1.1629-150000.5.78.1).

CVE-2025-30258 Severity: Low CVSS3 score: 2.7

Description: In GnuPG before 2.5.5, if a user chooses to import a certificate with certain crafted subkey data that lacks a valid backsig or that has incorrect usage flags, the user loses the ability to verify signatures made from certain other signing keys, aka a "verification DoS."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
gpg2 > 0-0 (version in image is 2.2.27-150300.3.8.1).

CVE-2023-53148 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:igb: Fix igb_down hung on surprise removalIn a setup where a Thunderbolt hub connects to Ethernet and a displaythrough USB Type-C, users may experience a hung task timeout when theyremove the cable between the PC and the Thunderbolt hub.This is because the igb_down function is called multiple times whenthe Thunderbolt hub is unplugged. For example, the igb_io_error_detectedtriggers the first call, and the igb_remove triggers the second call.The second call to igb_down will block at napi_synchronize.Here's the call trace: __schedule+0x3b0/0xddb ? __mod_timer+0x164/0x5d3 schedule+0x44/0xa8 schedule_timeout+0xb2/0x2a4 ? run_local_timers+0x4e/0x4e msleep+0x31/0x38 igb_down+0x12c/0x22a [igb 6615058754948bfde0bf01429257eb59f13030d4] __igb_close+0x6f/0x9c [igb 6615058754948bfde0bf01429257eb59f13030d4] igb_close+0x23/0x2b [igb 6615058754948bfde0bf01429257eb59f13030d4] __dev_close_many+0x95/0xec dev_close_many+0x6e/0x103 unregister_netdevice_many+0x105/0x5b1 unregister_netdevice_queue+0xc2/0x10d unregister_netdev+0x1c/0x23 igb_remove+0xa7/0x11c [igb 6615058754948bfde0bf01429257eb59f13030d4] pci_device_remove+0x3f/0x9c device_release_driver_internal+0xfe/0x1b4 pci_stop_bus_device+0x5b/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_bus_device+0x30/0x7f pci_stop_and_remove_bus_device+0x12/0x19 pciehp_unconfigure_device+0x76/0xe9 pciehp_disable_slot+0x6e/0x131 pciehp_handle_presence_or_link_change+0x7a/0x3f7 pciehp_ist+0xbe/0x194 irq_thread_fn+0x22/0x4d ? irq_thread+0x1fd/0x1fd irq_thread+0x17b/0x1fd ? irq_forced_thread_fn+0x5f/0x5f kthread+0x142/0x153 ? __irq_get_irqchip_state+0x46/0x46 ? kthread_associate_blkcg+0x71/0x71 ret_from_fork+0x1f/0x30In this case, igb_io_error_detected detaches the network interfaceand requests a PCIE slot reset, however, the PCIE reset callback isnot being invoked and thus the Ethernet connection breaks down.As the PCIE error in this case is a non-fatal one, requesting aslot reset can be avoided.This patch fixes the task hung issue and preserves Ethernetconnection by ignoring non-fatal PCIE errors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53200 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: x_tables: fix percpu counter block leak on error path when creating new netnsHere is the stack where we allocate percpu counter block: +-< __alloc_percpu +-< xt_percpu_counter_alloc +-< find_check_entry # {arp,ip,ip6}_tables.c +-< translate_tableAnd it can be leaked on this code path: +-> ip6t_register_table +-> translate_table # allocates percpu counter block +-> xt_register_table # failsthere is no freeing of the counter block on xt_register_table fail.Note: xt_percpu_counter_free should be called to free it like we do indo_replace through cleanup_entry helper (or in __ip6t_unregister_table).Probability of hitting this error path is low AFAICS (xt_register_tablecan only return ENOMEM here, as it is not replacing anything, as we arecreating new netns, and it is hard to imagine that all previousallocations succeeded and after that one in xt_register_table failed).But it's worth fixing even the rare leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-35938 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: decrease MHI channel buffer length to 8KBCurrently buf_len field of ath11k_mhi_config_qca6390 is assignedwith 0, making MHI use a default size, 64KB, to allocate channelbuffers. This is likely to fail in some scenarios where systemmemory is highly fragmented and memory compaction or reclaim isnot allowed.There is a fail report which is caused by it:kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfcebWorkqueue: events_unbound async_run_entry_fnCall Trace: dump_stack_lvl+0x47/0x60 warn_alloc+0x13a/0x1b0 ? srso_alias_return_thunk+0x5/0xfbef5 ? __alloc_pages_direct_compact+0xab/0x210 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0 __alloc_pages+0x32d/0x350 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __kmalloc_large_node+0x72/0x110 __kmalloc+0x37c/0x480 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814] device_for_each_child+0x5c/0xa0 ? __pfx_pci_pm_resume+0x10/0x10 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e] ? srso_alias_return_thunk+0x5/0xfbef5 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec] ? srso_alias_return_thunk+0x5/0xfbef5 dpm_run_callback+0x8c/0x1e0 device_resume+0x104/0x340 ? __pfx_dpm_watchdog_handler+0x10/0x10 async_resume+0x1d/0x30 async_run_entry_fn+0x32/0x120 process_one_work+0x168/0x330 worker_thread+0x2f5/0x410 ? __pfx_worker_thread+0x10/0x10 kthread+0xe8/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Actually those buffers are used only by QMI target -> host communication.And for WCN6855 and QCA6390, the largest packet size for that is lessthan 6KB. So change buf_len field to 8KB, which results in order 1allocation if page size is 4KB. In this way, we can at least save somememory, and as well as decrease the possibility of allocation failurein those scenarios.Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-38596 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk->sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur: BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28: unix_release_sock (net/unix/af_unix.c:640) unix_release (net/unix/af_unix.c:1050) sock_close (net/socket.c:659 net/socket.c:1421) __fput (fs/file_table.c:422) __fput_sync (fs/file_table.c:508) __se_sys_close (fs/open.c:1559 fs/open.c:1541) __x64_sys_close (fs/open.c:1541) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14: unix_stream_sendmsg (net/unix/af_unix.c:2273) __sock_sendmsg (net/socket.c:730 net/socket.c:745) ____sys_sendmsg (net/socket.c:2584) __sys_sendmmsg (net/socket.c:2638 net/socket.c:2724) __x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750) x64_sys_call (arch/x86/entry/syscall_64.c:33) do_syscall_64 (arch/x86/entry/common.c:?) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) value changed: 0x01 -> 0x03The line numbers are related to commit dd5a440a31fa ("Linux 6.9-rc7").Commit e1d09c2c2f57 ("af_unix: Fix data races around sk->sk_shutdown.")addressed a comparable issue in the past regarding sk->sk_shutdown.However, it overlooked resolving this particular data path.This patch only offending unix_stream_sendmsg() function, since theother reads seem to be protected by unix_state_lock() as discussed in

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46681 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:pktgen: use cpus_read_lock() in pg_net_init()I have seen the WARN_ON(smp_processor_id() != cpu) firingin pktgen_thread_worker() during tests.We must use cpus_read_lock()/cpus_read_unlock()around the for_each_online_cpu(cpu) loop.While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47710 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:sock_map: Add a cond_resched() in sock_hash_free()Several syzbot soft lockup reports all have in common sock_hash_free()If a map with a large number of buckets is destroyed, we need to yieldthe cpu when needed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56729 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Initialize cfid->tcon before performing network opsAvoid leaking a tcon ref when a lease break races with opening thecached directory. Processing the leak break might take a reference tothe tcon in cached_dir_lease_break() and then fail to release the ref incached_dir_offload_close, since cfid->tcon is still NULL.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37805 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:sound/virtio: Fix cancel_sync warnings on uninitialized work_structsBetty reported hitting the following warning:[ 8.709131][ T221] WARNING: CPU: 2 PID: 221 at kernel/workqueue.c:4182...[ 8.713282][ T221] Call trace:[ 8.713365][ T221] __flush_work+0x8d0/0x914[ 8.713468][ T221] __cancel_work_sync+0xac/0xfc[ 8.713570][ T221] cancel_work_sync+0x24/0x34[ 8.713667][ T221] virtsnd_remove+0xa8/0xf8 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.713868][ T221] virtsnd_probe+0x48c/0x664 [virtio_snd ab15f34d0dd772f6d11327e08a81d46dc9c36276][ 8.714035][ T221] virtio_dev_probe+0x28c/0x390[ 8.714139][ T221] really_probe+0x1bc/0x4c8...It seems we're hitting the error path in virtsnd_probe(), whichtriggers a virtsnd_remove() which iterates over the substreamscalling cancel_work_sync() on the elapsed_period work_struct.Looking at the code, from earlier in:virtsnd_probe()->virtsnd_build_devs()->virtsnd_pcm_parse_cfg()We set snd->nsubstreams, allocate the snd->substreams, and ifwe then hit an error on the info allocation or something invirtsnd_ctl_query_info() fails, we will exit without havinginitialized the elapsed_period work_struct.When that error path unwinds we then call virtsnd_remove()which as long as the substreams array is allocated, will iteratethrough calling cancel_work_sync() on the uninitialized workstruct hitting this warning.Takashi Iwai suggested this fix, which initializes the substreamsstructure right after allocation, so that if we hit the errorpaths we avoid trying to cleanup uninitialized data.Note: I have not yet managed to reproduce the issue myself, sothis patch has had limited testing.Feedback or thoughts would be appreciated!

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37857 Severity: Moderate CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: st: Fix array overflow in st_setup()Change the array size to follow parms size instead of a fixed value.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-66861 Severity: Moderate CVSS3 score: 2.5

Description: An issue was discovered in function d_unqualified_name in file cp-demangle.c in BinUtils 2.26 allowing attackers to cause a denial of service via crafted PE file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-66863 Severity: Moderate CVSS3 score: 2.5

Description: An issue was discovered in function d_discriminator in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-66866 Severity: Moderate CVSS3 score: 2.5

Description: An issue was discovered in function d_abi_tags in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2022-49614 Severity: Low CVSS3 score: 2.5

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50445 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: Reinject transport-mode packets through workqueueThe following warning is displayed when the tcp6-multi-diffip11 stresstest case of the LTP test suite is tested:watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [ns-tcpserver:48198]CPU: 0 PID: 48198 Comm: ns-tcpserver Kdump: loaded Not tainted 6.0.0-rc6+ #39Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : des3_ede_encrypt+0x27c/0x460 [libdes]lr : 0x3fsp : ffff80000ceaa1b0x29: ffff80000ceaa1b0 x28: ffff0000df056100 x27: ffff0000e51e5280x26: ffff80004df75030 x25: ffff0000e51e4600 x24: 000000000000003bx23: 0000000000802080 x22: 000000000000003d x21: 0000000000000038x20: 0000000080000020 x19: 000000000000000a x18: 0000000000000033x17: ffff0000e51e4780 x16: ffff80004e2d1448 x15: ffff80004e2d1248x14: ffff0000e51e4680 x13: ffff80004e2d1348 x12: ffff80004e2d1548x11: ffff80004e2d1848 x10: ffff80004e2d1648 x9 : ffff80004e2d1748x8 : ffff80004e2d1948 x7 : 000000000bcaf83d x6 : 000000000000001bx5 : ffff80004e2d1048 x4 : 00000000761bf3bf x3 : 000000007f1dd0a3x2 : ffff0000e51e4780 x1 : ffff0000e3b9a2f8 x0 : 00000000db44e872Call trace: des3_ede_encrypt+0x27c/0x460 [libdes] crypto_des3_ede_encrypt+0x1c/0x30 [des_generic] crypto_cbc_encrypt+0x148/0x190 crypto_skcipher_encrypt+0x2c/0x40 crypto_authenc_encrypt+0xc8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_rcv_established+0x3c8/0x720 tcp_v6_do_rcv+0xdc/0x4a0 tcp_v6_rcv+0xc24/0xcb0 ip6_protocol_deliver_rcu+0xf0/0x574 ip6_input_finish+0x48/0x7c ip6_input+0x48/0xc0 ip6_rcv_finish+0x80/0x9c xfrm_trans_reinject+0xb0/0xf4 tasklet_action_common.constprop.0+0xf8/0x134 tasklet_action+0x30/0x3c __do_softirq+0x128/0x368 do_softirq+0xb4/0xc0 __local_bh_enable_ip+0xb0/0xb4 put_cpu_fpsimd_context+0x40/0x70 kernel_neon_end+0x20/0x40 sha1_base_do_update.constprop.0.isra.0+0x11c/0x140 [sha1_ce] sha1_ce_finup+0x94/0x110 [sha1_ce] crypto_shash_finup+0x34/0xc0 hmac_finup+0x48/0xe0 crypto_shash_finup+0x34/0xc0 shash_digest_unaligned+0x74/0x90 crypto_shash_digest+0x4c/0x9c shash_ahash_digest+0xc8/0xf0 shash_async_digest+0x28/0x34 crypto_ahash_digest+0x48/0xcc crypto_authenc_genicv+0x88/0xcc [authenc] crypto_authenc_encrypt+0xd8/0xfc [authenc] crypto_aead_encrypt+0x2c/0x40 echainiv_encrypt+0x144/0x1a0 [echainiv] crypto_aead_encrypt+0x2c/0x40 esp6_output_tail+0x1c8/0x5d0 [esp6] esp6_output+0x120/0x278 [esp6] xfrm_output_one+0x458/0x4ec xfrm_output_resume+0x6c/0x1f0 xfrm_output+0xac/0x4ac __xfrm6_output+0x130/0x270 xfrm6_output+0x60/0xec ip6_xmit+0x2ec/0x5bc inet6_csk_xmit+0xbc/0x10c __tcp_transmit_skb+0x460/0x8c0 tcp_write_xmit+0x348/0x890 __tcp_push_pending_frames+0x44/0x110 tcp_push+0xb4/0x14c tcp_sendmsg_locked+0x71c/0xb64 tcp_sendmsg+0x40/0x6c inet6_sendmsg+0x4c/0x80 sock_sendmsg+0x5c/0x6c __sys_sendto+0x128/0x15c __arm64_sys_sendto+0x30/0x40 invoke_syscall+0x50/0x120 el0_svc_common.constprop.0+0x170/0x194 do_el0_svc+0x38/0x4c el0_svc+0x28/0xe0 el0t_64_sync_handler+0xbc/0x13c el0t_64_sync+0x180/0x184Get softirq info by bcc tool:./softirqs -NT 10Tracing soft irq event time... Hit Ctrl-C to end.15:34:34SOFTIRQ TOTAL_nsecsblock 158990timer 20030920sched 46577080net_rx 676746820tasklet 990606765015:34:45SOFTIRQ TOTAL_nsecsblock 86100sched 38849790net_rx ---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-52746 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr() int type = nla_type(nla); if (type > XFRMA_MAX) { return -EOPNOTSUPP; }@type is then used as an array index and can be usedas a Spectre v1 gadget. if (nla_len(nla) < compat_policy[type].len) {array_index_nospec() can be used to prevent leakingcontent of kernel memory to malicious users.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53639 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath6kl: reduce WARN to dev_dbg() in callbackThe warn is triggered on a known race condition, documented in the code abovethe test, that is correctly handled. Using WARN() hinders automated testing.Reducing severity.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53841 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:devlink: report devlink_port_type_warn source devicedevlink_port_type_warn is scheduled for port devlink and warningwhen the port type is not set. But from this warning it is not easyfound out which device (driver) has no devlink port set.[ 3709.975552] Type was not set for devlink port.[ 3709.975579] WARNING: CPU: 1 PID: 13092 at net/devlink/leftover.c:6775 devlink_port_type_warn+0x11/0x20[ 3709.993967] Modules linked in: openvswitch nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nfnetlink bluetooth rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs vhost_net vhost vhost_iotlb tap tun bridge stp llc qrtr intel_rapl_msr intel_rapl_common i10nm_edac nfit libnvdimm x86_pkg_temp_thermal mlx5_ib intel_powerclamp coretemp dell_wmi ledtrig_audio sparse_keymap ipmi_ssif kvm_intel ib_uverbs rfkill ib_core video kvm iTCO_wdt acpi_ipmi intel_vsec irqbypass ipmi_si iTCO_vendor_support dcdbas ipmi_devintf mei_me ipmi_msghandler rapl mei intel_cstate isst_if_mmio isst_if_mbox_pci dell_smbios intel_uncore isst_if_common i2c_i801 dell_wmi_descriptor wmi_bmof i2c_smbus intel_pch_thermal pcspkr acpi_power_meter xfs libcrc32c sd_mod sg nvme_tcp mgag200 i2c_algo_bit nvme_fabrics drm_shmem_helper drm_kms_helper nvme syscopyarea ahci sysfillrect sysimgblt nvme_core fb_sys_fops crct10dif_pclmul libahci mlx5_core sfc crc32_pclmul nvme_common drm[ 3709.994030] crc32c_intel mtd t10_pi mlxfw libata tg3 mdio megaraid_sas psample ghash_clmulni_intel pci_hyperv_intf wmi dm_multipath sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi fuse[ 3710.108431] CPU: 1 PID: 13092 Comm: kworker/1:1 Kdump: loaded Not tainted 5.14.0-319.el9.x86_64 #1[ 3710.108435] Hardware name: Dell Inc. PowerEdge R750/0PJ80M, BIOS 1.8.2 09/14/2022[ 3710.108437] Workqueue: events devlink_port_type_warn[ 3710.108440] RIP: 0010:devlink_port_type_warn+0x11/0x20[ 3710.108443] Code: 84 76 fe ff ff 48 c7 03 20 0e 1a ad 31 c0 e9 96 fd ff ff 66 0f 1f 44 00 00 0f 1f 44 00 00 48 c7 c7 18 24 4e ad e8 ef 71 62 ff <0f> 0b c3 cc cc cc cc 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f6 87[ 3710.108445] RSP: 0018:ff3b6d2e8b3c7e90 EFLAGS: 00010282[ 3710.108447] RAX: 0000000000000000 RBX: ff366d6580127080 RCX: 0000000000000027[ 3710.108448] RDX: 0000000000000027 RSI: 00000000ffff86de RDI: ff366d753f41f8c8[ 3710.108449] RBP: ff366d658ff5a0c0 R08: ff366d753f41f8c0 R09: ff3b6d2e8b3c7e18[ 3710.108450] R10: 0000000000000001 R11: 0000000000000023 R12: ff366d753f430600[ 3710.108451] R13: ff366d753f436900 R14: 0000000000000000 R15: ff366d753f436905[ 3710.108452] FS: 0000000000000000(0000) GS:ff366d753f400000(0000) knlGS:0000000000000000[ 3710.108453] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 3710.108454] CR2: 00007f1c57bc74e0 CR3: 000000111d26a001 CR4: 0000000000773ee0[ 3710.108456] PKRU: 55555554[ 3710.108457] Call Trace:[ 3710.108458] [ 3710.108459] process_one_work+0x1e2/0x3b0[ 3710.108466] ? rescuer_thread+0x390/0x390[ 3710.108468] worker_thread+0x50/0x3a0[ 3710.108471] ? rescuer_thread+0x390/0x390[ 3710.108473] kthread+0xdd/0x100[ 3710.108477] ? kthread_complete_and_exit+0x20/0x20[ 3710.108479] ret_from_fork+0x1f/0x30[ 3710.108485] [ 3710.108486] ---[ end trace 1b4b23cd0c65d6a0 ]---After patch:[ 402.473064] ice 0000:41:00.0: Type was not set for devlink port.[ 402.473064] ice 0000:41:00.1: Type was not set for devlink port.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41007 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:tcp: avoid too many retransmit packetsIf a TCP socket is using TCP_USER_TIMEOUT, and the other peerretracted its window to zero, tcp_retransmit_timer() canretransmit a packet every two jiffies (2 ms for HZ=1000),for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.The fix is to make sure tcp_rtx_probe0_timed_out() takesicsk->icsk_user_timeout into account.Before blamed commit, the socket would not timeout aftericsk->icsk_user_timeout, but would use standard exponentialbackoff for the retransmits.Also worth noting that before commit e89688e3e978 ("net: tcp:fix unexcepted socket die when snd_wnd is 0"), the issuewould last 2 minutes instead of 4.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47660 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:fsnotify: clear PARENT_WATCHED flags lazilyIn some setups directories can have many (usually negative) dentries.Hence __fsnotify_update_child_dentry_flags() function can take asignificant amount of time. Since the bulk of this function happensunder inode->i_lock this causes a significant contention on the lockwhen we remove the watch from the directory as the__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()races with __fsnotify_update_child_dentry_flags() calls from__fsnotify_parent() happening on children. This can lead upto softlockupreports reported by users.Fix the problem by calling fsnotify_update_children_dentry_flags() toset PARENT_WATCHED flags only when parent starts watching children.When parent stops watching children, clear false positive PARENT_WATCHEDflags lazily in __fsnotify_parent() for each accessed child.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56644 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/ipv6: release expired exception dst cached in socketDst objects get leaked in ip6_negative_advice() when this function isexecuted for an expired IPv6 route located in the exception table. Thereare several conditions that must be fulfilled for the leak to occur:* an ICMPv6 packet indicating a change of the MTU for the path is received, resulting in an exception dst being created* a TCP connection that uses the exception dst for routing packets must start timing out so that TCP begins retransmissions* after the exception dst expires, the FIB6 garbage collector must not run before TCP executes ip6_negative_advice() for the expired exception dstWhen TCP executes ip6_negative_advice() for an exception dst that hasexpired and if no other socket holds a reference to the exception dst, therefcount of the exception dst is 2, which corresponds to the incrementmade by dst_init() and the increment made by the TCP socket for which theconnection is timing out. The refcount made by the socket is neverreleased. The refcount of the dst is decremented in sk_dst_reset() butthat decrement is counteracted by a dst_hold() intentionally placed justbefore the sk_dst_reset() in ip6_negative_advice(). Afterip6_negative_advice() has finished, there is no other object tied to thedst. The socket lost its reference stored in sk_dst_cache and the dst isno longer in the exception table. The exception dst becomes a leakedobject.As a result of this dst leak, an unbalanced refcount is reported for theloopback device of a net namespace being destroyed under kernels that donot contain e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"):unregister_netdevice: waiting for lo to become free. Usage count = 2Fix the dst leak by removing the dst_hold() in ip6_negative_advice(). Thepatch that introduced the dst_hold() in ip6_negative_advice() was92f1655aa2b22 ("net: fix __dst_negative_advice() race"). But 92f1655aa2b22merely refactored the code with regards to the dst refcount so the issuewas present even before 92f1655aa2b22. The bug was introduced in54c1a859efd9f ("ipv6: Don't drop cache route entry unless timer actuallyexpired.") where the expired cached route is deleted and the sk_dst_cachemember of the socket is set to NULL by calling dst_negative_advice() butthe refcount belonging to the socket is left unbalanced.The IPv4 version - ipv4_negative_advice() - is not affected by this bug.When the TCP connection times out ipv4_negative_advice() merely resets thesk_dst_cache of the socket while decrementing the refcount of theexception dst.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56747 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()Hook "qedi_ops->common->sb_init = qed_sb_init" does not release the DMAmemory sb_virt when it fails. Add dma_free_coherent() to free it. Thisis the same way as qedr_alloc_mem_sb() and qede_alloc_mem_sb().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1150 Severity: Low CVSS3 score: 2.5

Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. This vulnerability affects the function bfd_malloc of the file libbfd.c of the component ld. The manipulation leads to memory leak. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1352 Severity: Low CVSS3 score: 2.5

Description: A vulnerability has been found in GNU elfutils 0.192 and classified as critical. This vulnerability affects the function __libdw_thread_tail in the library libdw_alloc.c of the component eu-readelf. The manipulation of the argument w leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 2636426a091bd6c6f7f02e49ab20d4cdc6bfc753. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).

CVE-2025-1376 Severity: Low CVSS3 score: 2.5

Description: A vulnerability classified as problematic was found in GNU elfutils 0.192. This vulnerability affects the function elf_strptr in the library /libelf/elf_strptr.c of the component eu-strip. The manipulation leads to denial of service. It is possible to launch the attack on the local host. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is b16f441cca0a4841050e3215a9f120a6d8aea918. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).

CVE-2025-21683 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix bpf_sk_select_reuseport() memory leakAs pointed out in the original comment, lookup in sockmap can return a TCPESTABLISHED socket. Such TCP socket may have had SO_ATTACH_REUSEPORT_EBPFset before it was ESTABLISHED. In other words, a non-NULL sk_reuseport_cbdoes not imply a non-refcounted socket.Drop sk's reference in both error paths.unreferenced object 0xffff888101911800 (size 2048): comm "test_progs", pid 44109, jiffies 4297131437 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 9336483b): __kmalloc_noprof+0x3bf/0x560 __reuseport_alloc+0x1d/0x40 reuseport_alloc+0xca/0x150 reuseport_attach_prog+0x87/0x140 sk_reuseport_attach_bpf+0xc8/0x100 sk_setsockopt+0x1181/0x1990 do_sock_setsockopt+0x12b/0x160 __sys_setsockopt+0x7b/0xc0 __x64_sys_setsockopt+0x1b/0x30 do_syscall_64+0x93/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22021 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: socket: Lookup orig tuple for IPv6 SNATnf_sk_lookup_slow_v4 does the conntrack lookup for IPv4 packets torestore the original 5-tuple in case of SNAT, to be able to find theright socket (if any). Then socket_match() can correctly check whetherthe socket was transparent.However, the IPv6 counterpart (nf_sk_lookup_slow_v6) lacks thisconntrack lookup, making xt_socket fail to match on the socket when thepacket was SNATed. Add the same logic to nf_sk_lookup_slow_v6.IPv6 SNAT is used in Kubernetes clusters for pod-to-world packets, aspods' addresses are in the fd00::/8 ULA subnet and need to be replacedwith the node's external address. Cilium leverages Envoy to enforce L7policies, and Envoy uses transparent sockets. Cilium inserts an iptablesprerouting rule that matches on `-m socket --transparent` and redirectsthe packets to localhost, but it fails to match SNATed IPv6 packets dueto that missing conntrack lookup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38058 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:__legitimize_mnt(): check for MNT_SYNC_UMOUNT should be under mount_lock... or we risk stealing final mntput from sync umount - raising mnt_countafter umount(2) has verified that victim is not busy, but before ithas set MNT_SYNC_UMOUNT; in that case __legitimize_mnt() doesn't seethat it's safe to quietly undo mnt_count increment and leaves droppingthe reference to caller, where it'll be a full-blown mntput().Check under mount_lock is needed; leaving the current one done beforetaking that makes no sense - it's nowhere near common enough to botherwith.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38103 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: usbhid: Eliminate recurrent out-of-bounds bug in usbhid_parse()Update struct hid_descriptor to better reflect the mandatory andoptional parts of the HID Descriptor as per USB HID 1.11 specification.Note: the kernel currently does not parse any optional HID classdescriptors, only the mandatory report descriptor.Update all references to member element desc[0] to rpt_desc.Add test to verify bLength and bNumDescriptors values are valid.Replace the for loop with direct access to the mandatory HID classdescriptor member for the report descriptor. This eliminates thepossibility of getting an out-of-bounds fault.Add a warning message if the HID descriptor contains any unsupportedoptional HID class descriptors.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39737 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:mm/kmemleak: avoid soft lockup in __kmemleak_do_cleanup()A soft lockup warning was observed on a relative small system x86-64system with 16 GB of memory when running a debug kernel with kmemleakenabled. watchdog: BUG: soft lockup - CPU#8 stuck for 33s! [kworker/8:1:134]The test system was running a workload with hot unplug happening inparallel. Then kemleak decided to disable itself due to its inability toallocate more kmemleak objects. The debug kernel has itsCONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE set to 40,000.The soft lockup happened in kmemleak_do_cleanup() when the existingkmemleak objects were being removed and deleted one-by-one in a loop via aworkqueue. In this particular case, there are at least 40,000 objectsthat need to be processed and given the slowness of a debug kernel and thefact that a raw_spinlock has to be acquired and released in__delete_object(), it could take a while to properly handle all theseobjects.As kmemleak has been disabled in this case, the object removal anddeletion process can be further optimized as locking isn't really needed. However, it is probably not worth the effort to optimize for such an edgecase that should rarely happen. So the simple solution is to callcond_resched() at periodic interval in the iteration loop to avoid softlockup.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40363 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipv6: fix field-spanning memcpy warning in AH outputFix field-spanning memcpy warnings in ah6_output() andah6_output_done() where extension headers are copied to/from IPv6address fields, triggering fortify-string warnings about writes beyondthe 16-byte address fields. memcpy: detected field-spanning write (size 40) of single field "&top_iph->saddr" at net/ipv6/ah6.c:439 (size 16) WARNING: CPU: 0 PID: 8838 at net/ipv6/ah6.c:439 ah6_output+0xe7e/0x14e0 net/ipv6/ah6.c:439The warnings are false positives as the extension headers areintentionally placed after the IPv6 header in memory. Fix by properlycopying addresses and extension headers separately, and introducehelper functions to avoid code duplication.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-6075 Severity: Low CVSS3 score: 2.5

Description: If the value passed to os.path.expandvars() is user-controlled a performance degradation is possible when expanding environment variables.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
libpython3_11-1_0 < 3.11.14-150400.9.69.1 (version in image is 3.11.13-150400.9.66.1).

CVE-2025-66864 Severity: Low CVSS3 score: 2.5

Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-66865 Severity: Low CVSS3 score: 2.5

Description: An issue was discovered in function d_print_comp_inner in file cp-demangle.c in BinUtils 2.26 allows attackers to cause a denial of service via crafted PE file.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils > 0-0 (version in image is 2.43-150100.7.52.1).

CVE-2025-71084 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/cm: Fix leaking the multicast GID table referenceIf the CM ID is destroyed while the CM event for multicast creating isstill queued the cancel_work_sync() will prevent the work from runningwhich also prevents destroying the ah_attr. This leaks a refcount andtriggers a WARN: GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 release_gid_table drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gid_table_release_one+0x284/0x3cc drivers/infiniband/core/cache.c:886Destroy the ah_attr after canceling the work, it is safe to call thistwice.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-22116 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:idpf: check error for register_netdev() on initCurrent init logic ignores the error code from register_netdev(),which will cause WARN_ON() on attempt to unregister it, if there was one,and there is no info for the user that the creation of the netdev failed.WARNING: CPU: 89 PID: 6902 at net/core/dev.c:11512 unregister_netdevice_many_notify+0x211/0x1a10...[ 3707.563641] unregister_netdev+0x1c/0x30[ 3707.563656] idpf_vport_dealloc+0x5cf/0xce0 [idpf][ 3707.563684] idpf_deinit_task+0xef/0x160 [idpf][ 3707.563712] idpf_vc_core_deinit+0x84/0x320 [idpf][ 3707.563739] idpf_remove+0xbf/0x780 [idpf][ 3707.563769] pci_device_remove+0xab/0x1e0[ 3707.563786] device_release_driver_internal+0x371/0x530[ 3707.563803] driver_detach+0xbf/0x180[ 3707.563816] bus_remove_driver+0x11b/0x2a0[ 3707.563829] pci_unregister_driver+0x2a/0x250Introduce an error check and log the vport number and error code.On removal make sure to check VPORT_REG_NETDEV flag prior to callingunregister and free on the netdev.Add local variables for idx, vport_config and netdev for readability.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37905 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Balance device refcount when destroying devicesUsing device_find_child() to lookup the proper SCMI device to destroycauses an unbalance in device refcount, since device_find_child() calls animplicit get_device(): this, in turns, inhibits the call of the providedrelease methods upon devices destruction.As a consequence, one of the structures that is not freed properly upondestruction is the internal struct device_private dev->p populated by thedrivers subsystem core.KMemleak detects this situation since loading/unloding some SCMI drivercauses related devices to be created/destroyed without calling anydevice_release method.unreferenced object 0xffff00000f583800 (size 512): comm "insmod", pid 227, jiffies 4294912190 hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6...... backtrace (crc 114e2eed): kmemleak_alloc+0xbc/0xd8 __kmalloc_cache_noprof+0x2dc/0x398 device_add+0x954/0x12d0 device_register+0x28/0x40 __scmi_device_create.part.0+0x1bc/0x380 scmi_device_create+0x2d0/0x390 scmi_create_protocol_devices+0x74/0xf8 scmi_device_request_notifier+0x1f8/0x2a8 notifier_call_chain+0x110/0x3b0 blocking_notifier_call_chain+0x70/0xb0 scmi_driver_register+0x350/0x7f0 0xffff80000a3b3038 do_one_initcall+0x12c/0x730 do_init_module+0x1dc/0x640 load_module+0x4b20/0x5b70 init_module_from_file+0xec/0x158$ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0device_add+0x954/0x12d0:kmalloc_noprof at include/linux/slab.h:901(inlined by) kzalloc_noprof at include/linux/slab.h:1037(inlined by) device_private_init at drivers/base/core.c:3510(inlined by) device_add at drivers/base/core.c:3561Balance device refcount by issuing a put_device() on devices found viadevice_find_child().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37925 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: reject on-disk inodes of an unsupported typeSyzbot has reported the following BUG:kernel BUG at fs/inode.c:668!Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTICPU: 3 UID: 0 PID: 139 Comm: jfsCommit Not tainted 6.12.0-rc4-syzkaller-00085-g4e46774408d9 #0Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014RIP: 0010:clear_inode+0x168/0x190Code: 4c 89 f7 e8 ba fe e5 ff e9 61 ff ff ff 44 89 f1 80 e1 07 80 c1 03 38 c1 7c c1 4c 89 f7 e8 90 ff e5 ff eb b7 0b e8 01 5d 7f ff 90 0f 0b e8 f9 5c 7f ff 90 0f 0b e8 f1 5c 7fRSP: 0018:ffffc900027dfae8 EFLAGS: 00010093RAX: ffffffff82157a87 RBX: 0000000000000001 RCX: ffff888104d4b980RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000RBP: ffffc900027dfc90 R08: ffffffff82157977 R09: fffff520004fbf38R10: dffffc0000000000 R11: fffff520004fbf38 R12: dffffc0000000000R13: ffff88811315bc00 R14: ffff88811315bda8 R15: ffff88811315bb80FS: 0000000000000000(0000) GS:ffff888135f00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00005565222e0578 CR3: 0000000026ef0000 CR4: 00000000000006f0Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? clear_inode+0x168/0x190 ? do_error_trap+0x1dc/0x2c0 ? clear_inode+0x168/0x190 ? __pfx_do_error_trap+0x10/0x10 ? report_bug+0x3cd/0x500 ? handle_invalid_op+0x34/0x40 ? clear_inode+0x168/0x190 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? clear_inode+0x57/0x190 ? clear_inode+0x167/0x190 ? clear_inode+0x168/0x190 ? clear_inode+0x167/0x190 jfs_evict_inode+0xb5/0x440 ? __pfx_jfs_evict_inode+0x10/0x10 evict+0x4ea/0x9b0 ? __pfx_evict+0x10/0x10 ? iput+0x713/0xa50 txUpdateMap+0x931/0xb10 ? __pfx_txUpdateMap+0x10/0x10 jfs_lazycommit+0x49a/0xb80 ? _raw_spin_unlock_irqrestore+0x8f/0x140 ? lockdep_hardirqs_on+0x99/0x150 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_default_wake_function+0x10/0x10 ? __kthread_parkme+0x169/0x1d0 ? __pfx_jfs_lazycommit+0x10/0x10 kthread+0x2f2/0x390 ? __pfx_jfs_lazycommit+0x10/0x10 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x4d/0x80 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 This happens when 'clear_inode()' makes an attempt to finalize an underlyingJFS inode of unknown type. According to JFS layout description fromhttps://jfs.sourceforge.net/project/pub/jfslayout.pdf, inode types from 5 to15 are reserved for future extensions and should not be encountered on a validfilesystem. So add an extra check for valid inode type in 'copy_from_dinode()'.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38045 Severity: Moderate CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix debug actions orderThe order of actions taken for debug was implemented incorrectly.Now we implemented the dump split and do the FW reset only in themiddle of the dump (rather than the FW killing itself on error.)As a result, some of the actions taken when applying the configwill now crash the device, so we need to fix the order.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-48714 Severity: Low CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Use VM_MAP instead of VM_ALLOC for ringbufAfter commit 2fd3fb0be1d1 ("kasan, vmalloc: unpoison VM_ALLOC pagesafter mapping"), non-VM_ALLOC mappings will be marked as accessiblein __get_vm_area_node() when KASAN is enabled. But now the flag forringbuf area is VM_ALLOC, so KASAN will complain out-of-bound accessafter vmap() returns. Because the ringbuf area is created by mappingallocated pages, so use VM_MAP instead.After the change, info in /proc/vmallocinfo also changes from [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmalloc userto [start]-[end] 24576 ringbuf_map_alloc+0x171/0x290 vmap user

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53261 Severity: Low CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:coresight: Fix memory leak in acpi_buffer->pointerThere are memory leaks reported by kmemleak:...unreferenced object 0xffff00213c141000 (size 1024): comm "systemd-udevd", pid 2123, jiffies 4294909467 (age 6062.160s) hex dump (first 32 bytes): 04 00 00 00 02 00 00 00 18 10 14 3c 21 00 ff ff ...........] __kmem_cache_alloc_node+0x2f8/0x348 [<00000000b0fc7ceb>] __kmalloc+0x58/0x108 [<0000000064ff4695>] acpi_os_allocate+0x2c/0x68 [<000000007d57d116>] acpi_ut_initialize_buffer+0x54/0xe0 [<0000000024583908>] acpi_evaluate_object+0x388/0x438 [<0000000017b2e72b>] acpi_evaluate_object_typed+0xe8/0x240 [<000000005df0eac2>] coresight_get_platform_data+0x1b4/0x988 [coresight]...The ACPI buffer memory (buf.pointer) should be freed. But the bufferis also used after returning from acpi_get_dsd_graph().Move the temporary variables buf to acpi_coresight_parse_graph(),and free it before the function return to prevent memory leak.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53585 Severity: Low CVSS3 score: 2.3

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: reject unhashed sockets in bpf_sk_assignThe semantics for bpf_sk_assign are as follows: sk = some_lookup_func() bpf_sk_assign(skb, sk) bpf_sk_release(sk)That is, the sk is not consumed by bpf_sk_assign. The functiontherefore needs to make sure that sk lives long enough to beconsumed from __inet_lookup_skb. The path through the stack for aTCPv4 packet is roughly: netif_receive_skb_core: takes RCU read lock __netif_receive_skb_core: sch_handle_ingress: tcf_classify: bpf_sk_assign() deliver_ptype_list_skb: deliver_skb: ip_packet_type->func == ip_rcv: ip_rcv_core: ip_rcv_finish_core: dst_input: ip_local_deliver: ip_local_deliver_finish: ip_protocol_deliver_rcu: tcp_v4_rcv: __inet_lookup_skb: skb_steal_sockThe existing helper takes advantage of the fact that everythinghappens in the same RCU critical section: for sockets withSOCK_RCU_FREE set bpf_sk_assign never takes a reference.skb_steal_sock then checks SOCK_RCU_FREE again and does sock_putif necessary.This approach assumes that SOCK_RCU_FREE is never set on a skbetween bpf_sk_assign and skb_steal_sock, but this invariant isviolated by unhashed UDP sockets. A new UDP socket is createdin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is onlyadded in udp_lib_get_port() which happens when a socket is bound.When bpf_sk_assign was added it wasn't possible to access unhashedUDP sockets from BPF, so this wasn't a problem. This changedin commit 0c48eefae712 ("sock_map: Lift socket state restrictionfor datagram sockets"), but the helper wasn't adjusted accordingly.The following sequence of events will therefore lead to a refcountleak:1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.2. Pull socket out of sockmap and bpf_sk_assign it. Since SOCK_RCU_FREE is not set we increment the refcount.3. bind() or connect() the socket, setting SOCK_RCU_FREE.4. skb_steal_sock will now set refcounted = false due to SOCK_RCU_FREE.5. tcp_v4_rcv() skips sock_put().Fix the problem by rejecting unhashed sockets in bpf_sk_assign().This matches the behaviour of __inet_lookup_skb which is ultimatelythe goal of bpf_sk_assign().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50583 Severity: Moderate CVSS3 score: 1.9

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid0, raid10: Don't set discard sectors for request queueIt should use disk_stack_limits to get a proper max_discard_sectorsrather than setting a value by stack drivers.And there is a bug. If all member disks are rotational devices,raid0/raid10 set max_discard_sectors. So the member devices arenot ssd/nvme, but raid0/raid10 export the wrong value. It reportswarning messages in function __blkdev_issue_discard when mkfs.xfslike this:[ 4616.022599] ------------[ cut here ]------------[ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0[ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0[ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff <0f> 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7[ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246[ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080[ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080[ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000[ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000[ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080[ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000[ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0[ 4616.236689] Call Trace:[ 4616.239428] blkdev_issue_discard+0x52/0xb0[ 4616.244108] blkdev_common_ioctl+0x43c/0xa00[ 4616.248883] blkdev_ioctl+0x116/0x280[ 4616.252977] __x64_sys_ioctl+0x8a/0xc0[ 4616.257163] do_syscall_64+0x5c/0x90[ 4616.261164] ? handle_mm_fault+0xc5/0x2a0[ 4616.265652] ? do_user_addr_fault+0x1d8/0x690[ 4616.270527] ? do_syscall_64+0x69/0x90[ 4616.274717] ? exc_page_fault+0x62/0x150[ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd[ 4616.284748] RIP: 0033:0x7f9a55398c6b

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37742 Severity: Moderate CVSS3 score: 1.9

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Fix uninit-value access of imap allocated in the diMount() functionsyzbot reports that hex_dump_to_buffer is using uninit-value:=====================================================BUG: KMSAN: uninit-value in hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171hex_dump_to_buffer+0x888/0x1100 lib/hexdump.c:171print_hex_dump+0x13d/0x3e0 lib/hexdump.c:276diFree+0x5ba/0x4350 fs/jfs/jfs_imap.c:876jfs_evict_inode+0x510/0x550 fs/jfs/inode.c:156evict+0x723/0xd10 fs/inode.c:796iput_final fs/inode.c:1946 [inline]iput+0x97b/0xdb0 fs/inode.c:1972txUpdateMap+0xf3e/0x1150 fs/jfs/jfs_txnmgr.c:2367txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]jfs_lazycommit+0x627/0x11d0 fs/jfs/jfs_txnmgr.c:2733kthread+0x6b9/0xef0 kernel/kthread.c:464ret_from_fork+0x6d/0x90 arch/x86/kernel/process.c:148ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244Uninit was created at:slab_post_alloc_hook mm/slub.c:4121 [inline]slab_alloc_node mm/slub.c:4164 [inline]__kmalloc_cache_noprof+0x8e3/0xdf0 mm/slub.c:4320kmalloc_noprof include/linux/slab.h:901 [inline]diMount+0x61/0x7f0 fs/jfs/jfs_imap.c:105jfs_mount+0xa8e/0x11d0 fs/jfs/jfs_mount.c:176jfs_fill_super+0xa47/0x17c0 fs/jfs/super.c:523get_tree_bdev_flags+0x6ec/0x910 fs/super.c:1636get_tree_bdev+0x37/0x50 fs/super.c:1659jfs_get_tree+0x34/0x40 fs/jfs/super.c:635vfs_get_tree+0xb1/0x5a0 fs/super.c:1814do_new_mount+0x71f/0x15e0 fs/namespace.c:3560path_mount+0x742/0x1f10 fs/namespace.c:3887do_mount fs/namespace.c:3900 [inline]__do_sys_mount fs/namespace.c:4111 [inline]__se_sys_mount+0x71f/0x800 fs/namespace.c:4088__x64_sys_mount+0xe4/0x150 fs/namespace.c:4088x64_sys_call+0x39bf/0x3c30 arch/x86/include/generated/asm/syscalls_64.h:166do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x77/0x7f=====================================================The reason is that imap is not properly initialized after memoryallocation. It will cause the snprintf() function to write uninitializeddata into linebuf within hex_dump_to_buffer().Fix this by using kzalloc instead of kmalloc to clear its content at thebeginning in diMount().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47623 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/fixmap: Fix VM debug warning on unmapUnmapping a fixmap entry is done by calling __set_fixmap()with FIXMAP_PAGE_CLEAR as flags.Today, powerpc __set_fixmap() calls map_kernel_page().map_kernel_page() is not happy when called a second timefor the same page. WARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8 CPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682 NIP: c0017cd4 LR: c00187f0 CTR: 00000010 REGS: e1011d50 TRAP: 0700 Not tainted (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty) MSR: 00029032 CR: 42000208 XER: 00000000 GPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c GPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 GPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000 NIP [c0017cd4] set_pte_at+0xc/0x1e8 LR [c00187f0] map_kernel_page+0x9c/0x100 Call Trace: [e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable) [e1011e30] [c0165fec] __set_fixmap+0x30/0x44 [e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170 [e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0 [e1011e90] [c0c03634] do_one_initcall+0x80/0x178 [e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250 [e1011f20] [c0007e34] kernel_init+0x24/0x140 [e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64 Instruction dump: 7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010 4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030Implement unmap_kernel_page() which clears an existing pte.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2021-47640 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix early region not updated correctlyThe shadow's page table is not updated when PTE_RPN_SHIFT is 24and PAGE_SHIFT is 12. It not only causes false positives butalso false negative as shown the following text.Fix it by bringing the logic of kasan_early_shadow_page_entry here.1. False Positive:==================================================================BUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50Write of size 16 at addr f57f3be0 by task swapper/0/1CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1Call Trace:[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0[c80d1cc0] [c03018a4] memset+0x34/0x90[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0[c80d1db0] [c2036580] init_sd+0xc4/0x1d0[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384[c80d1ef0] [c0004b14] kernel_init+0x24/0x170[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64Memory state around the buggy address: f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8==================================================================2. False Negative (with KASAN tests):==================================================================Before fix: ok 45 - kmalloc_double_kzfree # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039 KASAN failure expected in "((volatile char *)area)[3100]", but none occurred not ok 46 - vmalloc_oob not ok 1 - kasan==================================================================After fix: ok 1 - kasan

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49081 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:highmem: fix checks in __kmap_local_sched_{in,out}When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} checkthat even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots areinitialized with 0 value, but the check is done with pte_none. 0 ptehowever does not necessarily mean that pte_none will return true. e.g.on xtensa it returns false, resulting in the following runtime warnings: WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108 CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_out+0x51/0x108 __schedule+0x71a/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7f WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0 CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13 Call Trace: dump_stack+0xc/0x40 __warn+0x8f/0x174 warn_slowpath_fmt+0x48/0xac __kmap_local_sched_in+0x50/0xe0 finish_task_switch$isra$0+0x1ce/0x2f8 __schedule+0x86e/0x9c4 preempt_schedule_irq+0xa0/0xe0 common_exception_return+0x5c/0x93 do_wp_page+0x30e/0x330 handle_mm_fault+0xa70/0xc3c do_page_fault+0x1d8/0x3c4 common_exception+0x7f/0x7fFix it by replacing !pte_none(pteval) with pte_val(pteval) != 0.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-49567 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:mm/mempolicy: fix uninit-value in mpol_rebind_policy()mpol_set_nodemask()(mm/mempolicy.c) does not set up nodemask whenpol->mode is MPOL_LOCAL. Check pol->mode before accesspol->w.cpuset_mems_allowed in mpol_rebind_policy()(mm/mempolicy.c).BUG: KMSAN: uninit-value in mpol_rebind_policy mm/mempolicy.c:352 [inline]BUG: KMSAN: uninit-value in mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 mpol_rebind_policy mm/mempolicy.c:352 [inline] mpol_rebind_task+0x2ac/0x2c0 mm/mempolicy.c:368 cpuset_change_task_nodemask kernel/cgroup/cpuset.c:1711 [inline] cpuset_attach+0x787/0x15e0 kernel/cgroup/cpuset.c:2278 cgroup_migrate_execute+0x1023/0x1d20 kernel/cgroup/cgroup.c:2515 cgroup_migrate kernel/cgroup/cgroup.c:2771 [inline] cgroup_attach_task+0x540/0x8b0 kernel/cgroup/cgroup.c:2804 __cgroup1_procs_write+0x5cc/0x7a0 kernel/cgroup/cgroup-v1.c:520 cgroup1_tasks_write+0x94/0xb0 kernel/cgroup/cgroup-v1.c:539 cgroup_file_write+0x4c2/0x9e0 kernel/cgroup/cgroup.c:3852 kernfs_fop_write_iter+0x66a/0x9f0 fs/kernfs/file.c:296 call_write_iter include/linux/fs.h:2162 [inline] new_sync_write fs/read_write.c:503 [inline] vfs_write+0x1318/0x2030 fs/read_write.c:590 ksys_write+0x28b/0x510 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0xdb/0x120 fs/read_write.c:652 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeUninit was created at: slab_post_alloc_hook mm/slab.h:524 [inline] slab_alloc_node mm/slub.c:3251 [inline] slab_alloc mm/slub.c:3259 [inline] kmem_cache_alloc+0x902/0x11c0 mm/slub.c:3264 mpol_new mm/mempolicy.c:293 [inline] do_set_mempolicy+0x421/0xb70 mm/mempolicy.c:853 kernel_set_mempolicy mm/mempolicy.c:1504 [inline] __do_sys_set_mempolicy mm/mempolicy.c:1510 [inline] __se_sys_set_mempolicy+0x44c/0xb60 mm/mempolicy.c:1507 __x64_sys_set_mempolicy+0xd8/0x110 mm/mempolicy.c:1507 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82 entry_SYSCALL_64_after_hwframe+0x44/0xaeKMSAN: uninit-value in mpol_rebind_task (2)https://syzkaller.appspot.com/bug?id=d6eb90f952c2a5de9ea718a1b873c55cb13b59dcThis patch seems to fix below bug too.KMSAN: uninit-value in mpol_rebind_mm (2)https://syzkaller.appspot.com/bug?id=f2fecd0d7013f54ec4162f60743a2b28df40926bThe uninit-value is pol->w.cpuset_mems_allowed in mpol_rebind_policy().When syzkaller reproducer runs to the beginning of mpol_new(), mpol_new() mm/mempolicy.c do_mbind() mm/mempolicy.c kernel_mbind() mm/mempolicy.c`mode` is 1(MPOL_PREFERRED), nodes_empty(*nodes) is `true` and `flags`is 0. Then mode = MPOL_LOCAL; ... policy->mode = mode; policy->flags = flags;will be executed. So in mpol_set_nodemask(), mpol_set_nodemask() mm/mempolicy.c do_mbind() kernel_mbind()pol->mode is 4 (MPOL_LOCAL), that `nodemask` in `pol` is not initialized,which will be accessed in mpol_rebind_policy().

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53215 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:sched/fair: Don't balance task to its current running CPUWe've run into the case that the balancer tries to balance a migrationdisabled task and trigger the warning in set_task_cpu() like below: ------------[ cut here ]------------ WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240 Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip> CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G O 6.1.0-rc4+ #1 Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021 pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : set_task_cpu+0x188/0x240 lr : load_balance+0x5d0/0xc60 sp : ffff80000803bc70 x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040 x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001 x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78 x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000 x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000 x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530 x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001 Call trace: set_task_cpu+0x188/0x240 load_balance+0x5d0/0xc60 rebalance_domains+0x26c/0x380 _nohz_idle_balance.isra.0+0x1e0/0x370 run_rebalance_domains+0x6c/0x80 __do_softirq+0x128/0x3d8 ____do_softirq+0x18/0x24 call_on_irq_stack+0x2c/0x38 do_softirq_own_stack+0x24/0x3c __irq_exit_rcu+0xcc/0xf4 irq_exit_rcu+0x18/0x24 el1_interrupt+0x4c/0xe4 el1h_64_irq_handler+0x18/0x2c el1h_64_irq+0x74/0x78 arch_cpu_idle+0x18/0x4c default_idle_call+0x58/0x194 do_idle+0x244/0x2b0 cpu_startup_entry+0x30/0x3c secondary_start_kernel+0x14c/0x190 __secondary_switched+0xb0/0xb4 ---[ end trace 0000000000000000 ]---Further investigation shows that the warning is superfluous, the migrationdisabled task is just going to be migrated to its current running CPU.This is because that on load balance if the dst_cpu is not allowed by thetask, we'll re-select a new_dst_cpu as a candidate. If no task can bebalanced to dst_cpu we'll try to balance the task to the new_dst_cpuinstead. In this case when the migration disabled task is not on CPU itonly allows to run on its current CPU, load balance will select itscurrent CPU as new_dst_cpu and later triggers the warning above.The new_dst_cpu is chosen from the env->dst_grpmask. Currently itcontains CPUs in sched_group_span() and if we have overlapped groups it'spossible to run into this case. This patch makes env->dst_grpmask ofgroup_balance_mask() which exclude any CPUs from the busiest group andsolve the issue. For balancing in a domain with no overlapped groupsthe behaviour keeps same as before.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53243 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: add handling for RAID1C23/DUP to btrfs_reduce_alloc_profileCallers of `btrfs_reduce_alloc_profile` expect it to return exactlyone allocation profile flag, and failing to do so may ultimatelyresult in a WARN_ON and remount-ro when allocating new blocks, likethe below transaction abort on 6.1.`btrfs_reduce_alloc_profile` has two ways of determining the profile,first it checks if a conversion balance is currently running anduses the profile we're converting to. If no balance is currentlyrunning, it returns the max-redundancy profile which at least oneblock in the selected block group has.This works by simply checking each known allocation profile bit inredundancy order. However, `btrfs_reduce_alloc_profile` has not beenupdated as new flags have been added - first with the `DUP` profileand later with the RAID1C34 profiles.Because of the way it checks, if we have blocks with differentprofiles and at least one is known, that profile will be selected.However, if none are known we may return a flag set with multipleallocation profiles set.This is currently only possible when a balance from one of the threeunhandled profiles to another of the unhandled profiles is canceledafter allocating at least one block using the new profile.In that case, a transaction abort like the below will occur and thefilesystem will need to be mounted with -o skip_balance to get itmounted rw again (but the balance cannot be resumed without asimilar abort). [770.648] ------------[ cut here ]------------ [770.648] BTRFS: Transaction aborted (error -22) [770.648] WARNING: CPU: 43 PID: 1159593 at fs/btrfs/extent-tree.c:4122 find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] CPU: 43 PID: 1159593 Comm: btrfs Tainted: G W 6.1.0-0.deb11.7-powerpc64le #1 Debian 6.1.20-2~bpo11+1a~test [770.648] Hardware name: T2P9D01 REV 1.00 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV [770.648] NIP: c00800000f6784fc LR: c00800000f6784f8 CTR: c000000000d746c0 [770.648] REGS: c000200089afe9a0 TRAP: 0700 Tainted: G W (6.1.0-0.deb11.7-powerpc64le Debian 6.1.20-2~bpo11+1a~test) [770.648] MSR: 9000000002029033 CR: 28848282 XER: 20040000 [770.648] CFAR: c000000000135110 IRQMASK: 0 GPR00: c00800000f6784f8 c000200089afec40 c00800000f7ea800 0000000000000026 GPR04: 00000001004820c2 c000200089afea00 c000200089afe9f8 0000000000000027 GPR08: c000200ffbfe7f98 c000000002127f90 ffffffffffffffd8 0000000026d6a6e8 GPR12: 0000000028848282 c000200fff7f3800 5deadbeef0000122 c00000002269d000 GPR16: c0002008c7797c40 c000200089afef17 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000001 c000200008bc5a98 0000000000000001 GPR24: 0000000000000000 c0000003c73088d0 c000200089afef17 c000000016d3a800 GPR28: c0000003c7308800 c00000002269d000 ffffffffffffffea 0000000000000001 [770.648] NIP [c00800000f6784fc] find_free_extent+0x1d94/0x1e00 [btrfs] [770.648] LR [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] [770.648] Call Trace: [770.648] [c000200089afec40] [c00800000f6784f8] find_free_extent+0x1d90/0x1e00 [btrfs] (unreliable) [770.648] [c000200089afed30] [c00800000f681398] btrfs_reserve_extent+0x1a0/0x2f0 [btrfs] [770.648] [c000200089afeea0] [c00800000f681bf0] btrfs_alloc_tree_block+0x108/0x670 [btrfs] [770.648] [c000200089afeff0] [c00800000f66bd68] __btrfs_cow_block+0x170/0x850 [btrfs] [770.648] [c000200089aff100] [c00800000f66c58c] btrfs_cow_block+0x144/0x288 [btrfs] [770.648] [c000200089aff1b0] [c00800000f67113c] btrfs_search_slot+0x6b4/0xcb0 [btrfs] [770.648] [c000200089aff2a0] [c00800000f679f60] lookup_inline_extent_backref+0x128/0x7c0 [btrfs] [770.648] [c000200089aff3b0] [c00800000f67b338] lookup_extent_backref+0x70/0x190 [btrfs] [770.648] [c000200089aff470] [c00800000f67b54c] __btrfs_free_extent+0xf4/0x1490 [btrfs] [770.648] [---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53256 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Fix FFA device names for logical partitionsEach physical partition can provide multiple services each with UUID.Each such service can be presented as logical partition with a uniquecombination of VM ID and UUID. The number of distinct UUID in a systemwill be less than or equal to the number of logical partitions.However, currently it fails to register more than one logical partitionor service within a physical partition as the device name contains onlyVM ID while both VM ID and UUID are maintained in the partition information.The kernel complains with the below message: | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001' | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8 | Hardware name: FVP Base RevC (DT) | Call trace: | dump_backtrace+0xf8/0x118 | show_stack+0x18/0x24 | dump_stack_lvl+0x50/0x68 | dump_stack+0x18/0x24 | sysfs_create_dir_ns+0xe0/0x13c | kobject_add_internal+0x220/0x3d4 | kobject_add+0x94/0x100 | device_add+0x144/0x5d8 | device_register+0x20/0x30 | ffa_device_register+0x88/0xd8 | ffa_setup_partitions+0x108/0x1b8 | ffa_init+0x2ec/0x3a4 | do_one_initcall+0xcc/0x240 | do_initcall_level+0x8c/0xac | do_initcalls+0x54/0x94 | do_basic_setup+0x1c/0x28 | kernel_init_freeable+0x100/0x16c | kernel_init+0x20/0x1a0 | ret_from_fork+0x10/0x20 | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to | register things with the same name in the same directory. | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17 | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001By virtue of being random enough to avoid collisions when generated in adistributed system, there is no way to compress UUID keys to the numberof bits required to identify each. We can eliminate '-' in the name butit is not worth eliminating 4 bytes and add unnecessary logic for doingthat. Also v1.0 doesn't provide the UUID of the partitions which makesit hard to use the same for the device name.So to keep it simple, let us alloc an ID using ida_alloc() and append thesame to "arm-ffa" to make up a unique device name. Also stash the id valuein ffa_dev to help freeing the ID later when the device is destroyed.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53491 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:start_kernel: Add __no_stack_protector function attributeBack during the discussion ofcommit a9a3ed1eff36 ("x86: Fix early boot crash on gcc-10, third try")we discussed the need for a function attribute to control the omissionof stack protectors on a per-function basis; at the time Clang hadsupport for no_stack_protector but GCC did not. This was fixed ingcc-11. Now that the function attribute is available, let's start usingit.Callers of boot_init_stack_canary need to use this function attributeunless they're compiled with -fno-stack-protector, otherwise the canarystored in the stack slot of the caller will differ upon the call toboot_init_stack_canary. This will lead to a call to __stack_chk_fail()then panic.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-53510 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: core: Fix handling of lrbp->cmdufshcd_queuecommand() may be called two times in a row for a SCSI commandbefore it is completed. Hence make the following changes: - In the functions that submit a command, do not check the old value of lrbp->cmd nor clear lrbp->cmd in error paths. - In ufshcd_release_scsi_cmd(), do not clear lrbp->cmd.See also scsi_send_eh_cmnd().This commit prevents that the following appears if a command times out:WARNING: at drivers/ufs/core/ufshcd.c:2965 ufshcd_queuecommand+0x6f8/0x9a8Call trace: ufshcd_queuecommand+0x6f8/0x9a8 scsi_send_eh_cmnd+0x2c0/0x960 scsi_eh_test_devices+0x100/0x314 scsi_eh_ready_devs+0xd90/0x114c scsi_error_handler+0x2b4/0xb70 kthread+0x16c/0x1e0

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54145 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: drop unnecessary user-triggerable WARN_ONCE in verifierl logIt's trivial for user to trigger "verifier log line truncated" warning,as verifier has a fixed-sized buffer of 1024 bytes (as of now), and there are atleast two pieces of user-provided information that can be output throughthis buffer, and both can be arbitrarily sized by user: - BTF names; - BTF.ext source code lines strings.Verifier log buffer should be properly sized for typical verifier stateoutput. But it's sort-of expected that this buffer won't be long enoughin some circumstances. So let's drop the check. In any case code willwork correctly, at worst truncating a part of a single line output.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54185 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: remove BUG_ON()'s in add_new_free_space()At add_new_free_space() we have these BUG_ON()'s that are there to dealwith any failure to add free space to the in memory free space cache.Such failures are mostly -ENOMEM that should be very rare. However there'sno need to have these BUG_ON()'s, we can just return any error to thecaller and all callers and their upper call chain are already dealing witherrors.So just make add_new_free_space() return any errors, while removing theBUG_ON()'s, and returning the total amount of added free space to anoptional u64 pointer argument.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2023-54247 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Silence a warning in btf_type_id_size()syzbot reported a warning in [1] with the following stacktrace: WARNING: CPU: 0 PID: 5005 at kernel/bpf/btf.c:1988 btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... RIP: 0010:btf_type_id_size+0x2d9/0x9d0 kernel/bpf/btf.c:1988 ... Call Trace: map_check_btf kernel/bpf/syscall.c:1024 [inline] map_create+0x1157/0x1860 kernel/bpf/syscall.c:1198 __sys_bpf+0x127f/0x5420 kernel/bpf/syscall.c:5040 __do_sys_bpf kernel/bpf/syscall.c:5162 [inline] __se_sys_bpf kernel/bpf/syscall.c:5160 [inline] __x64_sys_bpf+0x79/0xc0 kernel/bpf/syscall.c:5160 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdWith the following btf [1] DECL_TAG 'a' type_id=4 component_idx=-1 [2] PTR '(anon)' type_id=0 [3] TYPE_TAG 'a' type_id=2 [4] VAR 'a' type_id=3, linkage=staticand when the bpf_attr.btf_key_type_id = 1 (DECL_TAG),the following WARN_ON_ONCE in btf_type_id_size() is triggered: if (WARN_ON_ONCE(!btf_type_is_modifier(size_type) && !btf_type_is_var(size_type))) return NULL;Note that 'return NULL' is the correct behavior as we don't wanta DECL_TAG type to be used as a btf_{key,value}_type_id evenfor the case like 'DECL_TAG -> STRUCT'. So thereis no correctness issue here, we just want to silence warning.To silence the warning, I added DECL_TAG as one of kinds inbtf_type_nosize() which will cause btf_type_id_size() returningNULL earlier without the warning. [1] https://lore.kernel.org/bpf/000000000000e0df8d05fc75ba86@google.com/

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-26907 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Fix fortify source warning while accessing Eth segment ------------[ cut here ]------------ memcpy: detected field-spanning write (size 56) of single field "eseg->inline_hdr.start" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy [last unloaded: mlx_compat(OE)] CPU: 0 PID: 293779 Comm: ssh Tainted: G OE 6.2.0-32-generic #32~22.04.1-Ubuntu Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80 FS: 00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x72/0x90 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? __warn+0x8d/0x160 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] ? report_bug+0x1bb/0x1d0 ? handle_bug+0x46/0x90 ? exc_invalid_op+0x19/0x80 ? asm_exc_invalid_op+0x1b/0x20 ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib] mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib] ipoib_send+0x2ec/0x770 [ib_ipoib] ipoib_start_xmit+0x5a0/0x770 [ib_ipoib] dev_hard_start_xmit+0x8e/0x1e0 ? validate_xmit_skb_list+0x4d/0x80 sch_direct_xmit+0x116/0x3a0 __dev_xmit_skb+0x1fd/0x580 __dev_queue_xmit+0x284/0x6b0 ? _raw_spin_unlock_irq+0xe/0x50 ? __flush_work.isra.0+0x20d/0x370 ? push_pseudo_header+0x17/0x40 [ib_ipoib] neigh_connected_output+0xcd/0x110 ip_finish_output2+0x179/0x480 ? __smp_call_single_queue+0x61/0xa0 __ip_finish_output+0xc3/0x190 ip_finish_output+0x2e/0xf0 ip_output+0x78/0x110 ? __pfx_ip_finish_output+0x10/0x10 ip_local_out+0x64/0x70 __ip_queue_xmit+0x18a/0x460 ip_queue_xmit+0x15/0x30 __tcp_transmit_skb+0x914/0x9c0 tcp_write_xmit+0x334/0x8d0 tcp_push_one+0x3c/0x60 tcp_sendmsg_locked+0x2e1/0xac0 tcp_sendmsg+0x2d/0x50 inet_sendmsg+0x43/0x90 sock_sendmsg+0x68/0x80 sock_write_iter+0x93/0x100 vfs_write+0x326/0x3c0 ksys_write+0xbd/0xf0 ? do_syscall_64+0x69/0x90 __x64_sys_write+0x19/0x30 do_syscall_---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-41041 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().syzkaller triggered the warning [0] in udp_v4_early_demux().In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcountof the looked-up sk and use sock_pfree() as skb->destructor, so we checkSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU graceperiod.Currently, SOCK_RCU_FREE is flagged for a bound socket after being putinto the hash table. Moreover, the SOCK_RCU_FREE check is done too earlyin udp_v[46]_early_demux() and sk_lookup(), so there could be a small racewindow: CPU1 CPU2 ---- ---- udp_v4_early_demux() udp_lib_get_port() | |- hlist_add_head_rcu() |- sk = __udp4_lib_demux_lookup() | |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk)); `- sock_set_flag(sk, SOCK_RCU_FREE)We had the same bug in TCP and fixed it in commit 871019b22d1b ("net:set SOCK_RCU_FREE before inserting socket into hashtable").Let's apply the same fix for UDP.[0]:WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599Modules linked in:CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92cRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004eFS: 00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600PKRU: 55555554Call Trace: ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447 NF_HOOK include/linux/netfilter.h:314 [inline] NF_HOOK include/linux/netfilter.h:308 [inline] ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738 netif_receive_skb_internal net/core/dev.c:5824 [inline] netif_receive_skb+0x271/0x300 net/core/dev.c:5884 tun_rx_batched drivers/net/tun.c:1549 [inline] tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048 new_sync_write fs/read_write.c:497 [inline] vfs_write+0x76f/0x8d0 fs/read_write.c:590 ksys_write+0xbf/0x190 fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __x64_sys_write+0x41/0x50 fs/read_write.c:652 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fc44a68bc1fCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1fR---truncated---

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-44983 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: flowtable: validate vlan headerEnsure there is sufficient room to access the protocol field of theVLAN header, validate it once before the flowtable lookup.=====================================================BUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_flow_offload_inet_hook+0x45a/0x5f0 net/netfilter/nf_flow_table_inet.c:32 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline] nf_ingress net/core/dev.c:5440 [inline]

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-46758 Severity: Moderate CVSS3 score: 0.0

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-47693 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:IB/core: Fix ib_cache_setup_one error flow cleanupWhen ib_cache_update return an error, we exit ib_cache_setup_oneinstantly with no proper cleanup, even though before this we hadalready successfully done gid_table_setup_one, that results inthe kernel WARN below.Do proper cleanup using gid_table_cleanup_one before returningthe err in order to fix the issue.WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0Modules linked in:CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:gid_table_release_one+0x181/0x1a0Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-53196 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Don't retire aborted MMIO instructionReturning an abort to the guest for an unsupported MMIO access is adocumented feature of the KVM UAPI. Nevertheless, it's clear that thisplumbing has seen limited testing, since userspace can trivially cause aWARN in the MMIO return: WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 Call trace: kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536 kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133 kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487 __do_sys_ioctl fs/ioctl.c:51 [inline] __se_sys_ioctl fs/ioctl.c:893 [inline] __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893 __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49 el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151 el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598The splat is complaining that KVM is advancing PC while an exception ispending, i.e. that KVM is retiring the MMIO instruction despite apending synchronous external abort. Womp womp.Fix the glaring UAPI bug by skipping over all the MMIO emulation incase there is a pending synchronous exception. Note that while userspaceis capable of pending an asynchronous exception (SError, IRQ, or FIQ),it is still safe to retire the MMIO instruction in this case as (1) theyare by definition asynchronous, and (2) KVM relies on hardware supportfor pending/delivering these exceptions instead of the software statemachine for advancing PC.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-56781 Severity: Moderate CVSS3 score: 0.0

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-57913 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Remove WARN_ON in functionfs_bindThis commit addresses an issue related to below kernel panic wherepanic_on_warn is enabled. It is caused by the unnecessary use of WARN_ONin functionsfs_bind, which easily leads to the following scenarios.1.adb_write in adbd 2. UDC write via configfs ================= =====================->usb_ffs_open_thread() ->UDC write ->open_functionfs() ->configfs_write_iter() ->adb_open() ->gadget_dev_desc_UDC_store() ->adb_write() ->usb_gadget_register_driver_owner ->driver_register()->StartMonitor() ->bus_add_driver() ->adb_read() ->gadget_bind_driver() ->configfs_composite_bind() ->usb_add_function()->open_functionfs() ->ffs_func_bind() ->adb_open() ->functionfs_bind() state !=FFS_ACTIVE>The adb_open, adb_read, and adb_write operations are invoked from thedaemon, but trying to bind the function is a process that is invoked byUDC write through configfs, which opens up the possibility of a racecondition between the two paths. In this race scenario, the kernel panicoccurs due to the WARN_ON from functionfs_bind when panic_on_warn isenabled. This commit fixes the kernel panic by removing the unnecessaryWARN_ON.Kernel panic - not syncing: kernel: panic_on_warn set ...[ 14.542395] Call trace:[ 14.542464] ffs_func_bind+0x1c8/0x14a8[ 14.542468] usb_add_function+0xcc/0x1f0[ 14.542473] configfs_composite_bind+0x468/0x588[ 14.542478] gadget_bind_driver+0x108/0x27c[ 14.542483] really_probe+0x190/0x374[ 14.542488] __driver_probe_device+0xa0/0x12c[ 14.542492] driver_probe_device+0x3c/0x220[ 14.542498] __driver_attach+0x11c/0x1fc[ 14.542502] bus_for_each_dev+0x104/0x160[ 14.542506] driver_attach+0x24/0x34[ 14.542510] bus_add_driver+0x154/0x270[ 14.542514] driver_register+0x68/0x104[ 14.542518] usb_gadget_register_driver_owner+0x48/0xf4[ 14.542523] gadget_dev_desc_UDC_store+0xf8/0x144[ 14.542526] configfs_write_iter+0xf0/0x138

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1149 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been classified as problematic. This affects the function xstrdup of the file libiberty/xmalloc.c of the component ld. The manipulation leads to memory leak. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1178 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been declared as problematic. Affected by this vulnerability is the function bfd_putl64 of the file libbfd.c of the component ld. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 75086e9de1707281172cc77f178e7949a4414ed0. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1179 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as critical. Affected by this issue is the function bfd_putl64 of the file bfd/libbfd.c of the component ld. The manipulation leads to memory corruption. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. Upgrading to version 2.44 is able to address this issue. It is recommended to upgrade the affected component. The code maintainer explains, that "[t]his bug has been fixed at some point between the 2.43 and 2.44 releases".

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1181 Severity: Moderate CVSS3 score: 0.0

Description: A vulnerability classified as critical was found in GNU Binutils 2.43. This vulnerability affects the function _bfd_elf_gc_mark_rsec of the file bfd/elflink.c of the component ld. The manipulation leads to memory corruption. The attack can be initiated remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. The exploit has been disclosed to the public and may be used. The name of the patch is 931494c9a89558acb36a03a340c01726545eef24. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-20054 Severity: Moderate CVSS3 score: None

Description: Uncaught exception in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-20103 Severity: Moderate CVSS3 score: None

Description: Insufficient resource pool in the core management mechanism for some Intel(R) Processors may allow an authenticated user to potentially enable denial of service via local access.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37835 Severity: Moderate CVSS3 score: None

Description: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37911 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix out-of-bound memcpy() during ethtool -wWhen retrieving the FW coredump using ethtool, it can sometimes causememory corruption:BUG: KFENCE: memory corruption in __bnxt_get_coredump+0x3ef/0x670 [bnxt_en]Corrupted memory at 0x000000008f0f30e8 [ ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ] (in kfence-#45):__bnxt_get_coredump+0x3ef/0x670 [bnxt_en]ethtool_get_dump_data+0xdc/0x1a0__dev_ethtool+0xa1e/0x1af0dev_ethtool+0xa8/0x170dev_ioctl+0x1b5/0x580sock_do_ioctl+0xab/0xf0sock_ioctl+0x1ce/0x2e0__x64_sys_ioctl+0x87/0xc0do_syscall_64+0x5c/0xf0entry_SYSCALL_64_after_hwframe+0x78/0x80...This happens when copying the coredump segment list inbnxt_hwrm_dbg_dma_data() with the HWRM_DBG_COREDUMP_LIST FW command.The info->dest_buf buffer is allocated based on the number of coredumpsegments returned by the FW. The segment list is then DMA'ed bythe FW and the length of the DMA is returned by FW. The driver thencopies this DMA'ed segment list to info->dest_buf.In some cases, this DMA length may exceed the info->dest_buf lengthand cause the above BUG condition. Fix it by capping the copylength to not exceed the length of info->dest_buf. The extraDMA data contains no useful information.This code path is shared for the HWRM_DBG_COREDUMP_LIST and theHWRM_DBG_COREDUMP_RETRIEVE FW commands. The buffering is differentfor these 2 FW commands. To simplify the logic, we need to movethe line to adjust the buffer length for HWRM_DBG_COREDUMP_RETRIEVEup, so that the new check to cap the copy length will work for bothcommands.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-37930 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: Fix WARN_ON in nouveau_fence_context_kill()Nouveau is mostly designed in a way that it's expected that fences onlyever get signaled through nouveau_fence_signal(). However, in at leastone other place, nouveau_fence_done(), can signal fences, too. If thathappens (race) a signaled fence remains in the pending list for a while,until it gets removed by nouveau_fence_update().Should nouveau_fence_context_kill() run in the meantime, this would bea bug because the function would attempt to set an error code on analready signaled fence.Have nouveau_fence_context_kill() check for a fence being signaled.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38037 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:vxlan: Annotate FDB data racesThe 'used' and 'updated' fields in the FDB entry structure can beaccessed concurrently by multiple threads, leading to reports such as[1]. Can be reproduced using [2].Suppress these reports by annotating these accesses usingREAD_ONCE() / WRITE_ONCE().[1]BUG: KCSAN: data-race in vxlan_xmit / vxlan_xmitwrite to 0xffff942604d263a8 of 8 bytes by task 286 on cpu 0: vxlan_xmit+0xb29/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fread to 0xffff942604d263a8 of 8 bytes by task 287 on cpu 2: vxlan_xmit+0xadf/0x2380 dev_hard_start_xmit+0x84/0x2f0 __dev_queue_xmit+0x45a/0x1650 packet_xmit+0x100/0x150 packet_sendmsg+0x2114/0x2ac0 __sys_sendto+0x318/0x330 __x64_sys_sendto+0x76/0x90 x64_sys_call+0x14e8/0x1c00 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7fvalue changed: 0x00000000fffbac6e -> 0x00000000fffbac6fReported by Kernel Concurrency Sanitizer on:CPU: 2 UID: 0 PID: 287 Comm: mausezahn Not tainted 6.13.0-rc7-01544-gb4b270f11a02 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014[2] #!/bin/bash set +H echo whitelist > /sys/kernel/debug/kcsan echo !vxlan_xmit > /sys/kernel/debug/kcsan ip link add name vx0 up type vxlan id 10010 dstport 4789 local 192.0.2.1 bridge fdb add 00:11:22:33:44:55 dev vx0 self static dst 198.51.100.1 taskset -c 0 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q & taskset -c 2 mausezahn vx0 -a own -b 00:11:22:33:44:55 -c 0 -q &

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38039 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Avoid WARN_ON when configuring MQPRIO with HTB offload enabledWhen attempting to enable MQPRIO while HTB offload is alreadyconfigured, the driver currently returns `-EINVAL` and triggers a`WARN_ON`, leading to an unnecessary call trace.Update the code to handle this case more gracefully by returning`-EOPNOTSUPP` instead, while also providing a helpful user message.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38043 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: arm_ffa: Set dma_mask for ffa devicesSet dma_mask for FFA devices, otherwise DMA allocation using the device pointerlead to following warning:WARNING: CPU: 1 PID: 1 at kernel/dma/mapping.c:597 dma_alloc_attrs+0xe0/0x124

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38044 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:media: cx231xx: set device_caps for 417The video_device for the MPEG encoder did not set device_caps.Add this, otherwise the video device can't be registered (you get aWARN_ON instead).Not seen before since currently 417 support is disabled, but I foundthis while experimenting with it.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-38324 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:mpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().As syzbot reported [0], mpls_route_input_rcu() can be calledfrom mpls_getroute(), where is under RTNL.net->mpls.platform_label is only updated under RTNL.Let's use rcu_dereference_rtnl() in mpls_route_input_rcu() tosilence the splat.[0]:WARNING: suspicious RCU usage6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted ----------------------------net/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!other info that might help us debug this:rcu_scheduler_active = 2, debug_locks = 11 lock held by syz.2.4451/17730: #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline] #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961stack backtrace:CPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025Call Trace: __dump_stack lib/dump_stack.c:94 [inline] dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120 lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865 mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84 mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381 rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964 netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534 netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline] netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883 sock_sendmsg_nosec net/socket.c:712 [inline] __sock_sendmsg net/socket.c:727 [inline] ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620 __sys_sendmmsg+0x200/0x420 net/socket.c:2709 __do_sys_sendmmsg net/socket.c:2736 [inline] __se_sys_sendmmsg net/socket.c:2733 [inline] __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7fRIP: 0033:0x7f0a2818e969Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133RAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969RDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003RBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39798 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:NFS: Fix the setting of capabilities when automounting a new filesystemCapabilities cannot be inherited when we cross into a new filesystem.They need to be reset to the minimal defaults, and then probed foragain.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-39801 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: Remove WARN_ON for device endpoint command timeoutsThis commit addresses a rarely observed endpoint command timeoutwhich causes kernel panic due to warn when 'panic_on_warn' is enabledand unnecessary call trace prints when 'panic_on_warn' is disabled.It is seen during fast software-controlled connect/disconnect testcases.The following is one such endpoint command timeout that we observed:1. Connect =======->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd2. Disconnect ==========->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmdIn the issue scenario, in Exynos platforms, we observed that controltransfers for the previous connect have not yet been completed and endtransfer command sent as a part of the disconnect sequence andprocessing of USB_ENDPOINT_HALT feature request from the host timeout.This maybe an expected scenario since the controller is processing EPcommands sent as a part of the previous connect. It maybe better toremove WARN_ON in all places where device endpoint commands are sent toavoid unnecessary kernel panic due to warn.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40102 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Prevent access to vCPU events before initAnother day, another syzkaller bug. KVM erroneously allows userspace topend vCPU events for a vCPU that hasn't been initialized yet, leading toKVM interpreting a bunch of uninitialized garbage for routing /injecting the exception.In one case the injection code and the hyp disagree on whether the vCPUhas a 32bit EL1 and put the vCPU into an illegal mode for AArch64,tripping the BUG() in exception_target_el() during the next injection: kernel BUG at arch/arm64/kvm/inject_fault.c:40! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP CPU: 3 UID: 0 PID: 318 Comm: repro Not tainted 6.17.0-rc4-00104-g10fd0285305d #6 PREEMPT Hardware name: linux,dummy-virt (DT) pstate: 21402009 (nzCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : exception_target_el+0x88/0x8c lr : pend_serror_exception+0x18/0x13c sp : ffff800082f03a10 x29: ffff800082f03a10 x28: ffff0000cb132280 x27: 0000000000000000 x26: 0000000000000000 x25: ffff0000c2a99c20 x24: 0000000000000000 x23: 0000000000008000 x22: 0000000000000002 x21: 0000000000000004 x20: 0000000000008000 x19: ffff0000c2a99c20 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 00000000200000c0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 x8 : ffff800082f03af8 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff800080f621f0 x4 : 0000000000000000 x3 : 0000000000000000 x2 : 000000000040009b x1 : 0000000000000003 x0 : ffff0000c2a99c20 Call trace: exception_target_el+0x88/0x8c (P) kvm_inject_serror_esr+0x40/0x3b4 __kvm_arm_vcpu_set_events+0xf0/0x100 kvm_arch_vcpu_ioctl+0x180/0x9d4 kvm_vcpu_ioctl+0x60c/0x9f4 __arm64_sys_ioctl+0xac/0x104 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x34/0xf0 el0t_64_sync_handler+0xa0/0xe4 el0t_64_sync+0x198/0x19c Code: f946bc01 b4fffe61 9101e020 17fffff2 (d4210000)Reject the ioctls outright as no sane VMM would call these beforeKVM_ARM_VCPU_INIT anyway. Even if it did the exception would've beenthrown away by the eventual reset of the vCPU's state.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-40104 Severity: Moderate CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:ixgbevf: fix mailbox API compatibility by negotiating supported featuresThere was backward compatibility in the terms of mailbox API. Variousdrivers from various OSes supporting 10G adapters from Intel portfoliocould easily negotiate mailbox API.This convention has been broken since introducing API 1.4.Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added supportfor IPSec which is specific only for the kernel ixgbe driver. None of therest of the Intel 10G PF/VF drivers supports it. And actually lack ofsupport was not included in the IPSec implementation - there were no suchcode paths. No possibility to negotiate support for the feature wasintroduced along with introduction of the feature itself.Commit 339f28964147 ("ixgbevf: Add support for new mailbox communicationbetween PF and VF") increasing API version to 1.5 did the same - itintroduced code supported specifically by the PF ESX driver. It altered APIversion for the VF driver in the same time not touching the versiondefined for the PF ixgbe driver. It led to additional discrepancies,as the code provided within API 1.6 cannot be supported for Linux ixgbedriver as it causes crashes.The issue was noticed some time ago and mitigated by Jake within the commitd0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").As a result we have regression for IPsec support and after increasing APIto version 1.6 ixgbevf driver stopped to support ESX MBX.To fix this mess add new mailbox op asking PF driver about supportedfeatures. Basing on a response determine whether to set support for IPSecand ESX-specific enhanced mailbox.New mailbox op, for compatibility purposes, must be added within new APIrevision, as API version of OOT PF & VF drivers is already increased to1.6 and doesn't incorporate features negotiate op.Features negotiation mechanism gives possibility to be extended with newfeatures when needed in the future.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2022-50575 Severity: Low CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:xen/privcmd: Fix a possible warning in privcmd_ioctl_mmap_resource()As 'kdata.num' is user-controlled data, if user tries to allocatememory larger than(>=) MAX_ORDER, then kcalloc() will fail, itcreates a stack trace and messes up dmesg with a warning.Call trace:-> privcmd_ioctl--> privcmd_ioctl_mmap_resourceAdd __GFP_NOWARN in order to avoid too large allocation warning.This is detected by static analysis using smatch.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default < 5.14.21-150400.24.184.1 (version in image is 5.14.21-150400.24.179.1).

CVE-2025-1148 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43 and classified as problematic. Affected by this issue is the function link_order_scan of the file ld/ldelfgen.c of the component ld. The manipulation leads to memory leak. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1151 Severity: Low CVSS3 score: 0.0

Description: A vulnerability was found in GNU Binutils 2.43. It has been rated as problematic. This issue affects the function xmemdup of the file xmemdup.c of the component ld. The manipulation leads to memory leak. The attack may be initiated remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1152 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. Affected is the function xstrdup of the file xstrdup.c of the component ld. The manipulation leads to memory leak. It is possible to launch the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue. The code maintainer explains: "I'm not going to commit some of the leak fixes I've been working on to the 2.44 branch due to concern that would destabilise ld. All of the reported leaks in this bugzilla have been fixed on binutils master."

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1153 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic was found in GNU Binutils 2.43/2.44. Affected by this vulnerability is the function bfd_set_format of the file format.c. The manipulation leads to memory corruption. The attack can be launched remotely. The complexity of an attack is rather high. The exploitation appears to be difficult. Upgrading to version 2.45 is able to address this issue. The identifier of the patch is 8d97c1a53f3dc9fd8e1ccdb039b8a33d50133150. It is recommended to upgrade the affected component.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1180 Severity: Low CVSS3 score: 0.0

Description: A vulnerability classified as problematic has been found in GNU Binutils 2.43. This affects the function _bfd_elf_write_section_eh_frame of the file bfd/elf-eh-frame.c of the component ld. The manipulation leads to memory corruption. It is possible to initiate the attack remotely. The complexity of an attack is rather high. The exploitability is told to be difficult. The exploit has been disclosed to the public and may be used. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
binutils < 2.45-150100.7.57.1 (version in image is 2.43-150100.7.52.1).

CVE-2025-1377 Severity: Low CVSS3 score: 0.0

Description: A vulnerability, which was classified as problematic, has been found in GNU elfutils 0.192. This issue affects the function gelf_getsymshndx of the file strip.c of the component eu-strip. The manipulation leads to denial of service. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The identifier of the patch is fbf1df9ca286de3323ae541973b08449f8d03aba. It is recommended to apply a patch to fix this issue.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
elfutils < 0.185-150400.5.8.3 (version in image is 0.185-150400.5.3.1).

CVE-2025-38048 Severity: Low CVSS3 score: 0.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_ring: Fix data race by tagging event_triggered as racy for KCSANsyzbot reports a data-race when accessing the event_triggered, here is thesimplified stack when the issue occurred:==================================================================BUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayedwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0: virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653 start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264 __netdev_start_xmit include/linux/netdevice.h:5151 [inline] netdev_start_xmit include/linux/netdevice.h:5160 [inline] xmit_one net/core/dev.c:3800 [inline]read to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1: virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline] virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566 skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777 vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715 __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158 handle_irq_event_percpu kernel/irq/handle.c:193 [inline]value changed: 0x01 -> 0x00==================================================================When the data race occurs, the function virtqueue_enable_cb_delayed() setsevent_triggered to false, and virtqueue_disable_cb_split/packed() reads itas false due to the race condition. Since event_triggered is an unreliablehint used for optimization, this should only cause the driver temporarilysuggest that the device not send an interrupt notification when the eventindex is used.Fix this KCSAN reported data-race issue by explicitly tagging the access asdata_racy.

Packages affected:

sles-release == 15.4 (version in image is 15.4-150400.58.10.2).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE-2024-24864 Severity: Not set CVSS3 score: 0.0

Description: A race condition was found in the Linux kernel's media/dvb-core in dvbdmx_write() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.

Packages affected:

sle-module-development-tools-release == 15.4 (version in image is 15.4-150400.55.1).
kernel-default > 0-0 (version in image is 5.14.21-150400.24.179.1).

CVE scan

Summary of CVEs affecting the image: