suse-sles-15-sp7-basic-v20260205-x86_64 CVE scan on 2026-02-05T19:33:46+00:00

CVE-2025-15467 Severity: Critical CVSS3 score: 9.8

Description: Issue summary: Parsing CMS AuthEnvelopedData message with maliciouslycrafted AEAD parameters can trigger a stack buffer overflow.Impact summary: A stack buffer overflow may lead to a crash, causing Denialof Service, or potentially remote code execution.When parsing CMS AuthEnvelopedData structures that use AEAD ciphers such asAES-GCM, the IV (Initialization Vector) encoded in the ASN.1 parameters iscopied into a fixed-size stack buffer without verifying that its length fitsthe destination. An attacker can supply a crafted CMS message with anoversized IV, causing a stack-based out-of-bounds write before anyauthentication or tag verification occurs.Applications and services that parse untrusted CMS or PKCS#7 content usingAEAD ciphers (e.g., S/MIME AuthEnvelopedData with AES-GCM) are vulnerable.Because the overflow occurs prior to authentication, no valid key materialis required to trigger it. While exploitability to remote code executiondepends on platform and toolchain mitigations, the stack-based writeprimitive represents a severe risk.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by thisissue, as the CMS implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3 and 3.0 are vulnerable to this issue.OpenSSL 1.1.1 and 1.0.2 are not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl3 < 3.2.3-150700.5.24.1 (version in image is 3.2.3-150700.5.21.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.7 (version in image is 15.7-150700.28.1).
cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).

CVE-2026-1299 Severity: Important CVSS3 score: 8.2

Description: The email module, specifically the "BytesGenerator" class, didn't properly quote newlines for email headers when serializing an email message allowing for header injection when an email is serialized. This is only applicable if using "LiteralHeader" writing headers that don't respect email folding rules, the new behavior will reject the incorrectly folded headers in "BytesGenerator".

Packages affected:

sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

CVE-2026-1484 Severity: Important CVSS3 score: 8.1

Description: A flaw was found in the GLib Base64 encoding routine when processing very large input data. Due to incorrect use of integer types during length calculation, the library may miscalculate buffer boundaries. This can cause memory writes outside the allocated buffer. Applications that process untrusted or extremely large Base64 input using GLib may crash or behave unpredictably.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glib2-tools < 2.78.6-150600.4.35.1 (version in image is 2.78.6-150600.4.25.1).

CVE-2026-1489 Severity: Important CVSS3 score: 8.1

Description: A flaw was found in GLib. An integer overflow vulnerability in its Unicode case conversion implementation can lead to memory corruption. By processing specially crafted and extremely large Unicode strings, an attacker could trigger an undersized memory allocation, resulting in out-of-bounds writes. This could cause applications utilizing GLib for string conversion to crash or become unstable.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glib2-tools < 2.78.6-150600.4.35.1 (version in image is 2.78.6-150600.4.25.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/64s: Fix VAS mm use after freeThe refcount on mm is dropped before the coprocessor is detached.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix missed ses refcountingUse new cifs_smb_ses_inc_refcount() helper to get an active referenceof @ses and @ses->dfs_root_ses (if set). This will prevent@ses->dfs_root_ses of being put in the next call to cifs_put_smb_ses()and thus potentially causing an use-after-free bug.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: cancel mesh send timer when hdev removedmesh_send_done timer is not canceled when hdev is removed, which causescrash if the timer triggers after hdev is gone.Cancel the timer when MGMT removes the hdev, like other MGMT timers.Should fix the BUG: sporadically seen by BlueZ test bot(in "Mesh - Send cancel - 1" test).Log:------BUG: KASAN: slab-use-after-free in run_timer_softirq+0x76b/0x7d0...Freed by task 36: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x43/0x70 kfree+0x103/0x500 device_release+0x9a/0x210 kobject_put+0x100/0x1e0 vhci_release+0x18b/0x240------

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
tar > 0-0 (version in image is 1.34-150000.3.34.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix UAF on kernel BO VA nodesIf the MMU is down, panthor_vm_unmap_range() might return an error.We expect the page table to be updated still, and if the MMU is blocked,the rest of the GPU should be blocked too, so no risk of accessingphysical memory returned to the system (which the current code doesn'tcover for anyway).Proceed with the rest of the cleanup instead of bailing out and leavingthe va_node inserted in the drm_mm, which leads to UAF when otheradjacent nodes are removed from the drm_mm tree.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glibc < 2.38-150600.14.40.1 (version in image is 2.38-150600.14.37.1).

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

Description: In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
gpg2 > 0-0 (version in image is 2.4.4-150600.3.12.1).

CVE-2016-5759 Severity: Moderate CVSS3 score: 7.8

Description: The mkdumprd script called "dracut" in the current working directory "." allows local users to trick the administrator into executing code as root.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
kdump < 2.0.18-150700.1.2 (version in image is 2.0.18+git2.g881ca8c-150700.3.3.2).

CVE-2026-24049 Severity: Important CVSS3 score: 7.7

Description: wheel is a command line tool for manipulating Python wheel files, as defined in PEP 427. In versions 0.40.0 through 0.46.1, the unpack function is vulnerable to file permission modification through mishandling of file permissions after extraction. The logic blindly trusts the filename from the archive header for the chmod operation, even though the extraction process itself might have sanitized the path. Attackers can craft a malicious wheel file that, when unpacked, changes the permissions of critical system files (e.g., /etc/passwd, SSH keys, config files), allowing for Privilege Escalation or arbitrary code execution by modifying now-writable scripts. This issue has been fixed in version 0.46.2.

Packages affected:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311-wheel > 0-0 (version in image is 0.42.0-150600.1.2).

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

Description: In the Linux kernel, the following vulnerability has been resolved:cifs: fix session state check in reconnect to avoid use-after-free issueDon't collect exiting session in smb2_reconnect_server(), because itwill be released soon.Note that the exiting session will stay in server->smb_ses_list untilit complete the cifs_free_ipc() and logoff() and then delete itselffrom the list.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).

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

Description: Malformed BRID/HHIT records can cause `named` to terminate unexpectedly.This issue affects BIND 9 versions 9.18.40 through 9.18.43, 9.20.13 through 9.20.17, 9.21.12 through 9.21.16, 9.18.40-S1 through 9.18.43-S1, and 9.20.13-S1 through 9.20.17-S1.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
bind-utils < 9.20.18-150700.3.15.1 (version in image is 9.20.15-150700.3.12.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python311 > 0-0 (version in image is 3.11.14-150600.3.38.1).

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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python3-pyasn1 > 0-0 (version in image is 0.4.2-150000.3.8.1).

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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python3-PyJWT > 0-0 (version in image is 2.4.0-150200.3.8.1).

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

Description: An integer overflow flaw was found in the Linux kernel. This issue leads to the kernel allocating `skb_shared_info` in the userspace, which is exploitable in systems without SMAP protection since `skb_shared_info` contains references to function pointers.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:FS: JFS: Check for read-only mounted filesystem in txBegin This patch adds a check for read-only mounted filesystem in txBegin before starting a transaction potentially saving from NULL pointer deref.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_remove_adv_monitor()KASAN reports that there's a use-after-free inhci_remove_adv_monitor(). Trawling through the disassembly, you cansee that the complaint is from the access in bt_dev_dbg() under theHCI_ADV_MONITOR_EXT_MSFT case. The problem case happens becausemsft_remove_monitor() can end up freeing the monitorstructure. Specifically: hci_remove_adv_monitor() -> msft_remove_monitor() -> msft_remove_monitor_sync() -> msft_le_cancel_monitor_advertisement_cb() -> hci_free_adv_monitor()Let's fix the problem by just stashing the relevant data when it'sstill valid.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net: bridge: fix use-after-free due to MST port state bypasssyzbot reported[1] a use-after-free when deleting an expired fdb. It isdue to a race condition between learning still happening and a port beingdeleted, after all its fdbs have been flushed. The port's state has beentoggled to disabled so no learning should happen at that time, but if wehave MST enabled, it will bypass the port's state, that together with VLANfiltering disabled can lead to fdb learning at a time when it shouldn'thappen while the port is being deleted. VLAN filtering must be disabledbecause we flush the port VLANs when it's being deleted which will stoplearning. This fix adds a check for the port's vlan group which isinitialized to NULL when the port is getting deleted, that avoids the portstate bypass. When MST is enabled there would be a minimal new overheadin the fast-path because the port's vlan group pointer is cache-hot.[1] https://syzkaller.appspot.com/bug?extid=dd280197f0f7ab3917be

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libsodium23 < 1.0.18-150000.4.14.1 (version in image is 1.0.18-150000.4.11.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:phy: tegra: xusb: Clear the driver reference in usb-phy devFor the dual-role port, it will assign the phy dev to usb-phy dev anduse the port dev driver as the dev driver of usb-phy.When we try to destroy the port dev, it will destroy its dev driveras well. But we did not remove the reference from usb-phy dev. Thismight cause the use-after-free issue in KASAN.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:maple_tree: fix potential out-of-bounds access in mas_wr_end_piv()Check the write offset end bounds before using it as the offset into thepivot array. This avoids a possible out-of-bounds access on the pivotarray if the write extends to the last slot in the node, in which case thenode maximum should be used as the end pivot.akpm: this doesn't affect any current callers, but new users of mapletreemay encounter this problem if backported into earlier kernels, so let'sfix it in -stable kernels in case of this.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Array index may go out of boundKlocwork reports array 'vha->host_str' of size 16 may use index value(s)16..19. Use snprintf() instead of sprintf().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:iomap: Fix possible overflow condition in iomap_write_delalloc_scanfolio_next_index() returns an unsigned long value which left shiftedby PAGE_SHIFT could possibly cause an overflow on 32-bit system. Insteaduse folio_pos(folio) + folio_size(folio), which does this correctly.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath9k: avoid referencing uninit memory in ath9k_wmi_ctrl_rxFor the reasons also described in commit b383e8abed41 ("wifi: ath9k: avoiduninit memory read in ath9k_htc_rx_msg()"), ath9k_htc_rx_msg() shouldvalidate pkt_len before accessing the SKB.For example, the obtained SKB may have been badly constructed withpkt_len = 8. In this case, the SKB can only contain a valid htc_frame_hdrbut after being processed in ath9k_htc_rx_msg() and passed toath9k_wmi_ctrl_rx() endpoint RX handler, it is expected to have a WMIcommand header which should be located inside its data payload.Implement sanity checking inside ath9k_wmi_ctrl_rx(). Otherwise, uninitmemory can be referenced.Tested on Qualcomm Atheros Communications AR9271 802.11n .Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable preemption in bpf_perf_event_outputThe nesting protection in bpf_perf_event_output relies on disabledpreemption, which is guaranteed for kprobes and tracepoints.However bpf_perf_event_output can be also called from uprobes contextthrough bpf_prog_run_array_sleepable function which disables migration,but keeps preemption enabled.This can cause task to be preempted by another one inside the nestingprotection and lead eventually to two tasks using same perf_sample_databuffer and cause crashes like: kernel tried to execute NX-protected page - exploit attempt? (uid: 0) BUG: unable to handle page fault for address: ffffffff82be3eea ... Call Trace: ? __die+0x1f/0x70 ? page_fault_oops+0x176/0x4d0 ? exc_page_fault+0x132/0x230 ? asm_exc_page_fault+0x22/0x30 ? perf_output_sample+0x12b/0x910 ? perf_event_output+0xd0/0x1d0 ? bpf_perf_event_output+0x162/0x1d0 ? bpf_prog_c6271286d9a4c938_krava1+0x76/0x87 ? __uprobe_perf_func+0x12b/0x540 ? uprobe_dispatcher+0x2c4/0x430 ? uprobe_notify_resume+0x2da/0xce0 ? atomic_notifier_call_chain+0x7b/0x110 ? exit_to_user_mode_prepare+0x13e/0x290 ? irqentry_exit_to_user_mode+0x5/0x30 ? asm_exc_int3+0x35/0x40Fixing this by disabling preemption in bpf_perf_event_output.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:irqchip/mchp-eic: Fix error code in mchp_eic_domain_alloc()If irq_domain_translate_twocell() sets "hwirq" to >= MCHP_EIC_NIRQ (2) thenit results in an out of bounds access.The code checks for invalid values, but doesn't set the error code. Return-EINVAL in that case, instead of returning success.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Return error for inconsistent extended attributesntfs_read_ea is called when we want to read extended attributes. Thereare some sanity checks for the validity of the EAs. However, it fails toreturn a proper error code for the inconsistent attributes, which mightlead to unpredicted memory accesses after return.[ 138.916927] BUG: KASAN: use-after-free in ntfs_set_ea+0x453/0xbf0[ 138.923876] Write of size 4 at addr ffff88800205cfac by task poc/199[ 138.931132][ 138.933016] CPU: 0 PID: 199 Comm: poc Not tainted 6.2.0-rc1+ #4[ 138.938070] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014[ 138.947327] Call Trace:[ 138.949557] [ 138.951539] dump_stack_lvl+0x4d/0x67[ 138.956834] print_report+0x16f/0x4a6[ 138.960798] ? ntfs_set_ea+0x453/0xbf0[ 138.964437] ? kasan_complete_mode_report_info+0x7d/0x200[ 138.969793] ? ntfs_set_ea+0x453/0xbf0[ 138.973523] kasan_report+0xb8/0x140[ 138.976740] ? ntfs_set_ea+0x453/0xbf0[ 138.980578] __asan_store4+0x76/0xa0[ 138.984669] ntfs_set_ea+0x453/0xbf0[ 138.988115] ? __pfx_ntfs_set_ea+0x10/0x10[ 138.993390] ? kernel_text_address+0xd3/0xe0[ 138.998270] ? __kernel_text_address+0x16/0x50[ 139.002121] ? unwind_get_return_address+0x3e/0x60[ 139.005659] ? __pfx_stack_trace_consume_entry+0x10/0x10[ 139.010177] ? arch_stack_walk+0xa2/0x100[ 139.013657] ? filter_irq_stacks+0x27/0x80[ 139.017018] ntfs_setxattr+0x405/0x440[ 139.022151] ? __pfx_ntfs_setxattr+0x10/0x10[ 139.026569] ? kvmalloc_node+0x2d/0x120[ 139.030329] ? kasan_save_stack+0x41/0x60[ 139.033883] ? kasan_save_stack+0x2a/0x60[ 139.037338] ? kasan_set_track+0x29/0x40[ 139.040163] ? kasan_save_alloc_info+0x1f/0x30[ 139.043588] ? __kasan_kmalloc+0x8b/0xa0[ 139.047255] ? __kmalloc_node+0x68/0x150[ 139.051264] ? kvmalloc_node+0x2d/0x120[ 139.055301] ? vmemdup_user+0x2b/0xa0[ 139.058584] __vfs_setxattr+0x121/0x170[ 139.062617] ? __pfx___vfs_setxattr+0x10/0x10[ 139.066282] __vfs_setxattr_noperm+0x97/0x300[ 139.070061] __vfs_setxattr_locked+0x145/0x170[ 139.073580] vfs_setxattr+0x137/0x2a0[ 139.076641] ? __pfx_vfs_setxattr+0x10/0x10[ 139.080223] ? __kasan_check_write+0x18/0x20[ 139.084234] do_setxattr+0xce/0x150[ 139.087768] setxattr+0x126/0x140[ 139.091250] ? __pfx_setxattr+0x10/0x10[ 139.094948] ? __virt_addr_valid+0xcb/0x140[ 139.097838] ? __call_rcu_common.constprop.0+0x1c7/0x330[ 139.102688] ? debug_smp_processor_id+0x1b/0x30[ 139.105985] ? kasan_quarantine_put+0x5b/0x190[ 139.109980] ? putname+0x84/0xa0[ 139.113886] ? __kasan_slab_free+0x11e/0x1b0[ 139.117961] ? putname+0x84/0xa0[ 139.121316] ? preempt_count_sub+0x1c/0xd0[ 139.124427] ? __mnt_want_write+0xae/0x100[ 139.127836] ? mnt_want_write+0x8f/0x150[ 139.130954] path_setxattr+0x164/0x180[ 139.133998] ? __pfx_path_setxattr+0x10/0x10[ 139.137853] ? __pfx_ksys_pwrite64+0x10/0x10[ 139.141299] ? debug_smp_processor_id+0x1b/0x30[ 139.145714] ? fpregs_assert_state_consistent+0x6b/0x80[ 139.150796] __x64_sys_setxattr+0x71/0x90[ 139.155407] do_syscall_64+0x3f/0x90[ 139.159035] entry_SYSCALL_64_after_hwframe+0x72/0xdc[ 139.163843] RIP: 0033:0x7f108cae4469[ 139.166481] Code: 00 f3 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 088[ 139.183764] RSP: 002b:00007fff87588388 EFLAGS: 00000286 ORIG_RAX: 00000000000000bc[ 139.190657] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f108cae4469[ 139.196586] RDX: 00007fff875883b0 RSI: 00007fff875883d1 RDI: 00007fff875883b6[ 139.201716] RBP: 00007fff8758c530 R08: 0000000000000001 R09: 00007fff8758c618[ 139.207940] R10: 0000000000000006 R11: 0000000000000286 R12: 00000000004004c0[ 139.214007] R13: 00007fff8758c610 R14: 0000000000000000 R15---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Move representor neigh cleanup to profile cleanup_txFor IP tunnel encapsulation in ECMP (Equal-Cost Multipath) mode, asthe flow is duplicated to the peer eswitch, the related neighbourinformation on the peer uplink representor is created as well.In the cited commit, eswitch devcom unpair is moved to uplink unloadAPI, specifically the profile->cleanup_tx. If there is a encap ruleoffloaded in ECMP mode, when one eswitch does unpair (because ofunloading the driver, for instance), and the peer rule from the peereswitch is going to be deleted, the use-after-free error is triggeredwhile accessing neigh info, as it is already cleaned up in uplink'sprofile->disable, which is before its profile->cleanup_tx.To fix this issue, move the neigh cleanup to profile's cleanup_txcallback, and after mlx5e_cleanup_uplink_rep_tx is called. The neighinit is moved to init_tx for symmeter.[ 2453.376299] BUG: KASAN: slab-use-after-free in mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.379125] Read of size 4 at addr ffff888127af9008 by task modprobe/2496[ 2453.381542] CPU: 7 PID: 2496 Comm: modprobe Tainted: G B 6.4.0-rc7+ #15[ 2453.383386] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014[ 2453.384335] Call Trace:[ 2453.384625] [ 2453.384891] dump_stack_lvl+0x33/0x50[ 2453.385285] print_report+0xc2/0x610[ 2453.385667] ? __virt_addr_valid+0xb1/0x130[ 2453.386091] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.386757] kasan_report+0xae/0xe0[ 2453.387123] ? mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.387798] mlx5e_rep_neigh_entry_release+0x109/0x3a0 [mlx5_core][ 2453.388465] mlx5e_rep_encap_entry_detach+0xa6/0xe0 [mlx5_core][ 2453.389111] mlx5e_encap_dealloc+0xa7/0x100 [mlx5_core][ 2453.389706] mlx5e_tc_tun_encap_dests_unset+0x61/0xb0 [mlx5_core][ 2453.390361] mlx5_free_flow_attr_actions+0x11e/0x340 [mlx5_core][ 2453.391015] ? complete_all+0x43/0xd0[ 2453.391398] ? free_flow_post_acts+0x38/0x120 [mlx5_core][ 2453.392004] mlx5e_tc_del_fdb_flow+0x4ae/0x690 [mlx5_core][ 2453.392618] mlx5e_tc_del_fdb_peers_flow+0x308/0x370 [mlx5_core][ 2453.393276] mlx5e_tc_clean_fdb_peer_flows+0xf5/0x140 [mlx5_core][ 2453.393925] mlx5_esw_offloads_unpair+0x86/0x540 [mlx5_core][ 2453.394546] ? mlx5_esw_offloads_set_ns_peer.isra.0+0x180/0x180 [mlx5_core][ 2453.395268] ? down_write+0xaa/0x100[ 2453.395652] mlx5_esw_offloads_devcom_event+0x203/0x530 [mlx5_core][ 2453.396317] mlx5_devcom_send_event+0xbb/0x190 [mlx5_core][ 2453.396917] mlx5_esw_offloads_devcom_cleanup+0xb0/0xd0 [mlx5_core][ 2453.397582] mlx5e_tc_esw_cleanup+0x42/0x120 [mlx5_core][ 2453.398182] mlx5e_rep_tc_cleanup+0x15/0x30 [mlx5_core][ 2453.398768] mlx5e_cleanup_rep_tx+0x6c/0x80 [mlx5_core][ 2453.399367] mlx5e_detach_netdev+0xee/0x120 [mlx5_core][ 2453.399957] mlx5e_netdev_change_profile+0x84/0x170 [mlx5_core][ 2453.400598] mlx5e_vport_rep_unload+0xe0/0xf0 [mlx5_core][ 2453.403781] mlx5_eswitch_unregister_vport_reps+0x15e/0x190 [mlx5_core][ 2453.404479] ? mlx5_eswitch_register_vport_reps+0x200/0x200 [mlx5_core][ 2453.405170] ? up_write+0x39/0x60[ 2453.405529] ? kernfs_remove_by_name_ns+0xb7/0xe0[ 2453.405985] auxiliary_bus_remove+0x2e/0x40[ 2453.406405] device_release_driver_internal+0x243/0x2d0[ 2453.406900] ? kobject_put+0x42/0x2d0[ 2453.407284] bus_remove_device+0x128/0x1d0[ 2453.407687] device_del+0x240/0x550[ 2453.408053] ? waiting_for_supplier_show+0xe0/0xe0[ 2453.408511] ? kobject_put+0xfa/0x2d0[ 2453.408889] ? __kmem_cache_free+0x14d/0x280[ 2453.409310] mlx5_rescan_drivers_locked.part.0+0xcd/0x2b0 [mlx5_core][ 2453.409973] mlx5_unregister_device+0x40/0x50 [mlx5_core][ 2453.410561] mlx5_uninit_one+0x3d/0x110 [mlx5_core][ 2453.411111] remove_one+0x89/0x130 [mlx5_core][ 24---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311 < 3.11.14-150600.3.41.2 (version in image is 3.11.14-150600.3.38.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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: 6lowpan: reset link-local header on ipv6 recv pathBluetooth 6lowpan.c netdev has header_ops, so it must set link-localheader for RX skb, otherwise things crash, eg. with AF_PACKET SOCK_RAWAdd missing skb_reset_mac_header() for uncompressed ipv6 RX path.For the compressed one, it is done in lowpan_header_decompress().Log: (BlueZ 6lowpan-tester Client Recv Raw - Success)------kernel BUG at net/core/skbuff.c:212!Call Trace:...packet_rcv (net/packet/af_packet.c:2152)...__local_bh_enable_ip (kernel/softirq.c:407)netif_rx (net/core/dev.c:5648)chan_recv_cb (net/bluetooth/6lowpan.c:294 net/bluetooth/6lowpan.c:359)------

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

CVE-2026-24401 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 versions 0.9rc2 and below, avahi-daemon can be crashed via a segmentation fault by sending an unsolicited mDNS response containing a recursive CNAME record, where the alias and canonical name point to the same domain (e.g., "h.local" as a CNAME for "h.local"). This causes unbounded recursion in the lookup_handle_cname function, leading to stack exhaustion. The vulnerability affects record browsers where AVAHI_LOOKUP_USE_MULTICAST is set explicitly, which includes record browsers created by resolvers used by nss-mdns. This issue is patched in commit 78eab31128479f06e30beb8c1cbf99dd921e2524.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libavahi-client3 > 0-0 (version in image is 0.8-150600.15.12.1).

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

Description: In libexpat before 2.7.4, the doContent function does not properly determine the buffer size bufSize because there is no integer overflow check for tag buffer reallocation.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: fix use-after-free in do_zone_finish()Shinichiro reported the following use-after-free triggered by the devicereplace operation in fstests btrfs/070. BTRFS info (device nullb1): scrub: finished on devid 1 with status: 0 ================================================================== BUG: KASAN: slab-use-after-free in do_zone_finish+0x91a/0xb90 [btrfs] Read of size 8 at addr ffff8881543c8060 by task btrfs-cleaner/3494007 CPU: 0 PID: 3494007 Comm: btrfs-cleaner Tainted: G W 6.8.0-rc5-kts #1 Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020 Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0x200/0x3e0 kasan_report+0xd8/0x110 ? do_zone_finish+0x91a/0xb90 [btrfs] ? do_zone_finish+0x91a/0xb90 [btrfs] do_zone_finish+0x91a/0xb90 [btrfs] btrfs_delete_unused_bgs+0x5e1/0x1750 [btrfs] ? __pfx_btrfs_delete_unused_bgs+0x10/0x10 [btrfs] ? btrfs_put_root+0x2d/0x220 [btrfs] ? btrfs_clean_one_deleted_snapshot+0x299/0x430 [btrfs] cleaner_kthread+0x21e/0x380 [btrfs] ? __pfx_cleaner_kthread+0x10/0x10 [btrfs] kthread+0x2e3/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x31/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 Allocated by task 3493983: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 __kasan_kmalloc+0xaa/0xb0 btrfs_alloc_device+0xb3/0x4e0 [btrfs] device_list_add.constprop.0+0x993/0x1630 [btrfs] btrfs_scan_one_device+0x219/0x3d0 [btrfs] btrfs_control_ioctl+0x26e/0x310 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Freed by task 3494056: kasan_save_stack+0x33/0x60 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3f/0x60 poison_slab_object+0x102/0x170 __kasan_slab_free+0x32/0x70 kfree+0x11b/0x320 btrfs_rm_dev_replace_free_srcdev+0xca/0x280 [btrfs] btrfs_dev_replace_finishing+0xd7e/0x14f0 [btrfs] btrfs_dev_replace_by_ioctl+0x1286/0x25a0 [btrfs] btrfs_ioctl+0xb27/0x57d0 [btrfs] __x64_sys_ioctl+0x134/0x1b0 do_syscall_64+0x99/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 The buggy address belongs to the object at ffff8881543c8000 which belongs to the cache kmalloc-1k of size 1024 The buggy address is located 96 bytes inside of freed 1024-byte region [ffff8881543c8000, ffff8881543c8400) The buggy address belongs to the physical page: page:00000000fe2c1285 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1543c8 head:00000000fe2c1285 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 flags: 0x17ffffc0000840(slab|head|node=0|zone=2|lastcpupid=0x1fffff) page_type: 0xffffffff() raw: 0017ffffc0000840 ffff888100042dc0 ffffea0019e8f200 dead000000000002 raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8881543c7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff8881543c7f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff8881543c8000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff8881543c8080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8881543c8100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fbThis UAF happens because we're accessing stale zone information of aalready removed btrfs_device in do_zone_finish().The sequence of events is as follows:btrfs_dev_replace_start btrfs_scrub_dev btrfs_dev_replace_finishing btrfs_dev_replace_update_device_in_mapping_tree <-- devices replaced btrfs_rm_dev_replace_free_srcdev btrfs_free_device <-- device freedcleaner_kthread btrfs_delete_unused_bgs btrfs_zone_finish do_zone_finish <-- refers the freed deviceThe reason for this is that we're using a---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:nvmet-fc: avoid scheduling association deletion twiceWhen forcefully shutting down a port via the configfs interface,nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() andthen nvmet_disable_port(). Both functions will eventually schedule allremaining associations for deletion.The current implementation checks whether an association is about to beremoved, but only after the work item has already been scheduled. As aresult, it is possible for the first scheduled work item to free allresources, and then for the same work item to be scheduled again fordeletion.Because the association list is an RCU list, it is not possible to takea lock and remove the list entry directly, so it cannot be looked upagain. Instead, a flag (terminating) must be used to determine whetherthe association is already in the process of being deleted.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:soundwire: fix enumeration completionThe soundwire subsystem uses two completion structures that allowdrivers to wait for soundwire device to become enumerated on the bus andinitialised by their drivers, respectively.The code implementing the signalling is currently broken as it does notsignal all current and future waiters and also uses the wrongreinitialisation function, which can potentially lead to memorycorruption if there are still waiters on the queue.Not signalling future waiters specifically breaks sound card probedeferrals as codec drivers can not tell that the soundwire device isalready attached when being reprobed. Some codec runtime PMimplementations suffer from similar problems as waiting for enumerationduring resume can also timeout despite the device already having beenenumerated.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:driver: soc: xilinx: use _safe loop iterator to avoid a use after freeThe hash_for_each_possible() loop dereferences "eve_data" to get thenext item on the list. However the loop frees eve_data so it leads toa use after free. Use hash_for_each_possible_safe() instead.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:fs/jfs: prevent double-free in dbUnmount() after failed jfs_remount()Syzkaller reported the following issue:==================================================================BUG: KASAN: double-free in slab_free mm/slub.c:3787 [inline]BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3800Free of addr ffff888086408000 by task syz-executor.4/12750[...]Call Trace: [...] kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:482 ____kasan_slab_free+0xfb/0x120 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807 slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3800 dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264 jfs_umount+0x248/0x3b0 fs/jfs/jfs_umount.c:87 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:1386 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 cleanup_mnt+0x494/0x520 fs/namespace.c:1291 task_work_run+0x243/0x300 kernel/task_work.c:179 resume_user_mode_work include/linux/resume_user_mode.h:49 [inline] exit_to_user_mode_loop+0x124/0x150 kernel/entry/common.c:171 exit_to_user_mode_prepare+0xb2/0x140 kernel/entry/common.c:203 __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline] syscall_exit_to_user_mode+0x26/0x60 kernel/entry/common.c:296 do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x63/0xcd[...] Allocated by task 13352: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 ____kasan_kmalloc mm/kasan/common.c:371 [inline] __kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380 kmalloc include/linux/slab.h:580 [inline] dbMount+0x54/0x980 fs/jfs/jfs_dmap.c:164 jfs_mount+0x1dd/0x830 fs/jfs/jfs_mount.c:121 jfs_fill_super+0x590/0xc50 fs/jfs/super.c:556 mount_bdev+0x26c/0x3a0 fs/super.c:1359 legacy_get_tree+0xea/0x180 fs/fs_context.c:610 vfs_get_tree+0x88/0x270 fs/super.c:1489 do_new_mount+0x289/0xad0 fs/namespace.c:3145 do_mount fs/namespace.c:3488 [inline] __do_sys_mount fs/namespace.c:3697 [inline] __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674 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/0xcdFreed by task 13352: kasan_save_stack mm/kasan/common.c:45 [inline] kasan_set_track+0x3d/0x60 mm/kasan/common.c:52 kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518 ____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236 kasan_slab_free include/linux/kasan.h:177 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807 slab_free mm/slub.c:3787 [inline] __kmem_cache_free+0x71/0x110 mm/slub.c:3800 dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264 jfs_mount_rw+0x545/0x740 fs/jfs/jfs_mount.c:247 jfs_remount+0x3db/0x710 fs/jfs/super.c:454 reconfigure_super+0x3bc/0x7b0 fs/super.c:935 vfs_fsconfig_locked fs/fsopen.c:254 [inline] __do_sys_fsconfig fs/fsopen.c:439 [inline] __se_sys_fsconfig+0xad5/0x1060 fs/fsopen.c:314 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_SBI(ipbmap->i_sb)->bmap wasn't set to NULL after kfree() indbUnmount().Syzkaller uses faultinject to reproduce this KASAN double-freewarning. The issue is triggered if either diMount() or dbMount() failin jfs_remount(), since diUnmount() or dbUnmount() already happened insuch a case - they will do double-free on next execution: jfs_umountor jfs_remount.Tested on both upstream and jfs-next by syzkaller.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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

Description: In the Linux kernel, the following vulnerability has been resolved:tpm: tpm_vtpm_proxy: fix a race condition in /dev/vtpmx creation/dev/vtpmx is made visible before 'workqueue' is initialized, which canlead to a memory corruption in the worst case scenario.Address this by initializing 'workqueue' as the very first step of thedriver initialization.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40302 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:media: videobuf2: forbid remove_bufs when legacy fileio is activevb2_ioctl_remove_bufs() call manipulates queue internal buffer list,potentially overwriting some pointers used by the legacy fileio accessmode. Forbid that ioctl when fileio is active to protect internal queuestate between subsequent read/write calls.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68331 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transferWhen a UAS device is unplugged during data transfer, there isa probability of a system panic occurring. The root cause isan access to an invalid memory address during URB callback handling.Specifically, this happens when the dma_direct_unmap_sg() functionis called within the usb_hcd_unmap_urb_for_dma() interface, but thesg->dma_address field is 0 and the sg data structure has already beenfreed.The SCSI driver sends transfer commands by invoking uas_queuecommand_lck()in uas.c, using the uas_submit_urbs() function to submit requests to USB.Within the uas_submit_urbs() implementation, three URBs (sense_urb,data_urb, and cmd_urb) are sequentially submitted. Device removal mayoccur at any point during uas_submit_urbs execution, which may resultin URB submission failure. However, some URBs might have been successfullysubmitted before the failure, and uas_submit_urbs will return the -ENODEVerror code in this case. The current error handling directly callsscsi_done(). In the SCSI driver, this eventually triggers scsi_complete()to invoke scsi_end_request() for releasing the sgtable. The successfullysubmitted URBs, when being unlinked to giveback, callusb_hcd_unmap_urb_for_dma() in hcd.c, leading to exceptions during sgunmapping operations since the sg data structure has already been freed.This patch modifies the error condition check in the uas_submit_urbs()function. When a UAS device is removed but one or more URBs have alreadybeen successfully submitted to USB, it avoids immediately invokingscsi_done() and save the cmnd to devinfo->cmnd array. If the successfullysubmitted URBs is completed before devinfo->resetting being set, thenthe scsi_done() function will be called within uas_try_complete() afterall pending URB operations are finalized. Otherwise, the scsi_done()function will be called within uas_zap_pending(), which is executed afterusb_kill_anchored_urbs().The error handling only takes effect when uas_queuecommand_lck() callsuas_submit_urbs() and returns the error value -ENODEV . In this case,the device is disconnected, and the flow proceeds to uas_disconnect(),where uas_zap_pending() is invoked to call uas_try_complete().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68339 Severity: Moderate CVSS3 score: 6.3

Description: In the Linux kernel, the following vulnerability has been resolved:atm/fore200e: Fix possible data race in fore200e_open()Protect access to fore200e->available_cell_rate with rate_mtx lock in theerror handling path of fore200e_open() to prevent a data race.The field fore200e->available_cell_rate is a shared resource used to trackavailable bandwidth. It is concurrently accessed by fore200e_open(),fore200e_close(), and fore200e_change_qos().In fore200e_open(), the lock rate_mtx is correctly held when subtractingvcc->qos.txtp.max_pcr from available_cell_rate to reserve bandwidth.However, if the subsequent call to fore200e_activate_vcin() fails, thefunction restores the reserved bandwidth by adding back toavailable_cell_rate without holding the lock.This introduces a race condition because available_cell_rate is a globaldevice resource shared across all VCCs. If the error path infore200e_open() executes concurrently with operations likefore200e_close() or fore200e_change_qos() on other VCCs, aread-modify-write race occurs.Specifically, the error path reads the rate without the lock. If anotherCPU acquires the lock and modifies the rate (e.g., releasing bandwidth infore200e_close()) between this read and the subsequent write, the errorpath will overwrite the concurrent update with a stale value. This resultsin incorrect bandwidth accounting.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68160 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Writing large, newline-free data into a BIO chain using theline-buffering filter where the next BIO performs short writes can triggera heap-based out-of-bounds write.Impact summary: This out-of-bounds write can cause memory corruption whichtypically results in a crash, leading to Denial of Service for an application.The line-buffering BIO filter (BIO_f_linebuffer) is not used by default inTLS/SSL data paths. In OpenSSL command-line applications, it is typicallyonly pushed onto stdout/stderr on VMS systems. Third-party applications thatexplicitly use this filter with a BIO chain that can short-write and thatwrite large, newline-free data influenced by an attacker would be affected.However, the circumstances where this could happen are unlikely to be underattacker control, and BIO_f_linebuffer is unlikely to be handling non-curateddata controlled by an attacker. For that reason the issue was assessed asLow severity.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the BIO implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.1).

CVE-2025-69419 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Calling PKCS12_get_friendlyname() function on a maliciouslycrafted PKCS#12 file with a BMPString (UTF-16BE) friendly name containingnon-ASCII BMP code point can trigger a one byte write before the allocatedbuffer.Impact summary: The out-of-bounds write can cause a memory corruptionwhich can have various consequences including a Denial of Service.The OPENSSL_uni2utf8() function performs a two-pass conversion of a PKCS#12BMPString (UTF-16BE) to UTF-8. In the second pass, when emitting UTF-8 bytes,the helper function bmp_to_utf8() incorrectly forwards the remaining UTF-16source byte count as the destination buffer capacity to UTF8_putc(). For BMPcode points above U+07FF, UTF-8 requires three bytes, but the forwardedcapacity can be just two bytes. UTF8_putc() then returns -1, and this negativevalue is added to the output length without validation, causing thelength to become negative. The subsequent trailing NUL byte is then writtenat a negative offset, causing write outside of heap allocated buffer.The vulnerability is reachable via the public PKCS12_get_friendlyname() APIwhen parsing attacker-controlled PKCS#12 files. While PKCS12_parse() uses adifferent code path that avoids this issue, PKCS12_get_friendlyname() directlyinvokes the vulnerable function. Exploitation requires an attacker to providea malicious PKCS#12 file to be parsed by the application and the attackercan just trigger a one zero byte write before the allocated buffer.For that reason the issue was assessed as Low severity according to ourSecurity Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.1).

CVE-2025-69421 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: Processing a malformed PKCS#12 file can trigger a NULL pointerdereference in the PKCS12_item_decrypt_d2i_ex() function.Impact summary: A NULL pointer dereference can trigger a crash which leads toDenial of Service for an application processing PKCS#12 files.The PKCS12_item_decrypt_d2i_ex() function does not check whether the octparameter is NULL before dereferencing it. When called fromPKCS12_unpack_p7encdata() with a malformed PKCS#12 file, this parameter canbe NULL, causing a crash. The vulnerability is limited to Denial of Serviceand cannot be escalated to achieve code execution or memory disclosure.Exploiting this issue requires an attacker to provide a malformed PKCS#12 fileto an application that processes it. For that reason the issue was assessed asLow severity according to our Security Policy.The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.1).

CVE-2026-22795 Severity: Moderate CVSS3 score: 6.2

Description: Issue summary: An invalid or NULL pointer dereference can happen inan application processing a malformed PKCS#12 file.Impact summary: An application processing a malformed PKCS#12 file can becaused to dereference an invalid or NULL pointer on memory read, resultingin a Denial of Service.A type confusion vulnerability exists in PKCS#12 parsing code wherean ASN1_TYPE union member is accessed without first validating the type,causing an invalid pointer read.The location is constrained to a 1-byte address space, meaning anyattempted pointer manipulation can only target addresses between 0x00 and 0xFF.This range corresponds to the zero page, which is unmapped on most modernoperating systems and will reliably result in a crash, leading only to aDenial of Service. Exploiting this issue also requires a user or applicationto process a maliciously crafted PKCS#12 file. It is uncommon to acceptuntrusted PKCS#12 files in applications as they are usually used to storeprivate keys which are trusted by definition. For these reasons, the issuewas assessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS12 implementation is outside the OpenSSL FIPS module boundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.1).

CVE-2023-54089 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_pmem: add the missing REQ_OP_WRITE for flush bioWhen doing mkfs.xfs on a pmem device, the following warning was ------------[ cut here ]------------ WARNING: CPU: 2 PID: 384 at block/blk-core.c:751 submit_bio_noacct Modules linked in: CPU: 2 PID: 384 Comm: mkfs.xfs Not tainted 6.4.0-rc7+ #154 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:submit_bio_noacct+0x340/0x520 ...... Call Trace: ? submit_bio_noacct+0xd5/0x520 submit_bio+0x37/0x60 async_pmem_flush+0x79/0xa0 nvdimm_flush+0x17/0x40 pmem_submit_bio+0x370/0x390 __submit_bio+0xbc/0x190 submit_bio_noacct_nocheck+0x14d/0x370 submit_bio_noacct+0x1ef/0x520 submit_bio+0x55/0x60 submit_bio_wait+0x5a/0xc0 blkdev_issue_flush+0x44/0x60The root cause is that submit_bio_noacct() needs bio_op() is eitherWRITE or ZONE_APPEND for flush bio and async_pmem_flush() doesn't assignREQ_OP_WRITE when allocating flush bio, so submit_bio_noacct just failthe flush bio.Simply fix it by adding the missing REQ_OP_WRITE for flush bio. And wecould fix the flush order issue and do flush optimization later.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54104 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: fsl_upm: Fix an off-by one test in fun_exec_op()'op-cs' is copied in 'fun->mchip_number' which is used to access the'mchip_offsets' and the 'rnb_gpio' arrays.These arrays have NAND_MAX_CHIPS elements, so the index must be below thislimit.Fix the sanity check in order to avoid the NAND_MAX_CHIPS value. Thiswould lead to out-of-bound accesses.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54255 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:sh: dma: Fix DMA channel offset calculationVarious SoCs of the SH3, SH4 and SH4A family, which use this driver,feature a differing number of DMA channels, which can be distributedbetween up to two DMAC modules. The existing implementation fails tocorrectly accommodate for all those variations, resulting in wrongchannel offset calculations and leading to kernel panics.Rewrite dma_base_addr() in order to properly calculate channel offsetsin a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so thatthe correct DMAC module base is selected for the DMAOR register.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54293 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:bcache: fixup btree_cache_wait list damageWe get a kernel crash about "list_add corruption. next->prev should beprev (ffff9c801bc01210), but was ffff9c77b688237c.(next=ffffae586d8afe68)."crash> struct list_head 0xffff9c801bc01210struct list_head { next = 0xffffae586d8afe68, prev = 0xffffae586d8afe68}crash> struct list_head 0xffff9c77b688237cstruct list_head { next = 0x0, prev = 0x0}crash> struct list_head 0xffffae586d8afe68struct list_head struct: invalid kernel virtual address: ffffae586d8afe68 type: "gdb_readmem_callback"Cannot access memory at address 0xffffae586d8afe68[230469.019492] Call Trace:[230469.032041] prepare_to_wait+0x8a/0xb0[230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache][230469.056533] mca_cannibalize_lock+0x72/0x90 [escache][230469.068788] mca_alloc+0x2ae/0x450 [escache][230469.080790] bch_btree_node_get+0x136/0x2d0 [escache][230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache][230469.104382] ? finish_wait+0x80/0x80[230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache][230469.127259] kthread+0x112/0x130[230469.138448] ? kthread_flush_work_fn+0x10/0x10[230469.149477] ret_from_fork+0x35/0x40bch_btree_check_thread() and bch_dirty_init_thread() may callmca_cannibalize() to cannibalize other cached btree nodes. Only one threadcan do it at a time, so the op of other threads will be added to thebtree_cache_wait list.We must call finish_wait() to remove op from btree_cache_wait before freeit's memory address. Otherwise, the list will be damaged. Also should callbch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_upother waiters.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54302 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix data race on CQP completion statsCQP completion statistics is read lockesly in irdma_wait_event andirdma_check_cqp_progress while it can be updated in the completionthread irdma_sc_ccq_get_cqe_info on another CPU as KCSAN reports.Make completion statistics an atomic variable to reflect coherent updatesto it. This will also avoid load/store tearing logic bug potentiallypossible by compiler optimizations.[77346.170861] BUG: KCSAN: data-race in irdma_handle_cqp_op [irdma] / irdma_sc_ccq_get_cqe_info [irdma][77346.171383] write to 0xffff8a3250b108e0 of 8 bytes by task 9544 on cpu 4:[77346.171483] irdma_sc_ccq_get_cqe_info+0x27a/0x370 [irdma][77346.171658] irdma_cqp_ce_handler+0x164/0x270 [irdma][77346.171835] cqp_compl_worker+0x1b/0x20 [irdma][77346.172009] process_one_work+0x4d1/0xa40[77346.172024] worker_thread+0x319/0x700[77346.172037] kthread+0x180/0x1b0[77346.172054] ret_from_fork+0x22/0x30[77346.172136] read to 0xffff8a3250b108e0 of 8 bytes by task 9838 on cpu 2:[77346.172234] irdma_handle_cqp_op+0xf4/0x4b0 [irdma][77346.172413] irdma_cqp_aeq_cmd+0x75/0xa0 [irdma][77346.172592] irdma_create_aeq+0x390/0x45a [irdma][77346.172769] irdma_rt_init_hw.cold+0x212/0x85d [irdma][77346.172944] irdma_probe+0x54f/0x620 [irdma][77346.173122] auxiliary_bus_probe+0x66/0xa0[77346.173137] really_probe+0x140/0x540[77346.173154] __driver_probe_device+0xc7/0x220[77346.173173] driver_probe_device+0x5f/0x140[77346.173190] __driver_attach+0xf0/0x2c0[77346.173208] bus_for_each_dev+0xa8/0xf0[77346.173225] driver_attach+0x29/0x30[77346.173240] bus_add_driver+0x29c/0x2f0[77346.173255] driver_register+0x10f/0x1a0[77346.173272] __auxiliary_driver_register+0xbc/0x140[77346.173287] irdma_init_module+0x55/0x1000 [irdma][77346.173460] do_one_initcall+0x7d/0x410[77346.173475] do_init_module+0x81/0x2c0[77346.173491] load_module+0x1232/0x12c0[77346.173506] __do_sys_finit_module+0x101/0x180[77346.173522] __x64_sys_finit_module+0x3c/0x50[77346.173538] do_syscall_64+0x39/0x90[77346.173553] entry_SYSCALL_64_after_hwframe+0x63/0xcd[77346.173634] value changed: 0x0000000000000094 -> 0x0000000000000095

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40213 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: fix crash in set_mesh_sync and set_mesh_completeThere is a BUG: KASAN: stack-out-of-bounds in set_mesh_sync due tomemcpy from badly declared on-stack flexible array.Another crash is in set_mesh_complete() due to double list_del viamgmt_pending_valid + mgmt_pending_remove.Use DEFINE_FLEX to declare the flexible array right, and don't memcpyoutside bounds.As mgmt_pending_valid removes the cmd from list, use mgmt_pending_free,and also report status on error.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40357 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix general protection fault in __smc_diag_dumpThe syzbot report a crash: Oops: general protection fault, probably for non-canonical address 0xfbd5a5d5a0000003: 0000 [#1] SMP KASAN NOPTI KASAN: maybe wild-memory-access in range [0xdead4ead00000018-0xdead4ead0000001f] CPU: 1 UID: 0 PID: 6949 Comm: syz.0.335 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025 RIP: 0010:smc_diag_msg_common_fill net/smc/smc_diag.c:44 [inline] RIP: 0010:__smc_diag_dump.constprop.0+0x3ca/0x2550 net/smc/smc_diag.c:89 Call Trace: smc_diag_dump_proto+0x26d/0x420 net/smc/smc_diag.c:217 smc_diag_dump+0x27/0x90 net/smc/smc_diag.c:234 netlink_dump+0x539/0xd30 net/netlink/af_netlink.c:2327 __netlink_dump_start+0x6d6/0x990 net/netlink/af_netlink.c:2442 netlink_dump_start include/linux/netlink.h:341 [inline] smc_diag_handler_dump+0x1f9/0x240 net/smc/smc_diag.c:251 __sock_diag_cmd net/core/sock_diag.c:249 [inline] sock_diag_rcv_msg+0x438/0x790 net/core/sock_diag.c:285 netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552 netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline] netlink_unicast+0x5a7/0x870 net/netlink/af_netlink.c:1346 netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896 sock_sendmsg_nosec net/socket.c:714 [inline] __sock_sendmsg net/socket.c:729 [inline] ____sys_sendmsg+0xa95/0xc70 net/socket.c:2614 ___sys_sendmsg+0x134/0x1d0 net/socket.c:2668 __sys_sendmsg+0x16d/0x220 net/socket.c:2700 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0xcd/0x4e0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x77/0x7f The process like this: (CPU1) | (CPU2) ---------------------------------|------------------------------- inet_create() | // init clcsock to NULL | sk = sk_alloc() | | // unexpectedly change clcsock | inet_init_csk_locks() | | // add sk to hash table | smc_inet_init_sock() | smc_sk_init() | smc_hash_sk() | | // traverse the hash table | smc_diag_dump_proto | __smc_diag_dump() | // visit wrong clcsock | smc_diag_msg_common_fill() // alloc clcsock | smc_create_clcsk | sock_create_kern |With CONFIG_DEBUG_LOCK_ALLOC=y, the smc->clcsock is unexpectedly changedin inet_init_csk_locks(). The INET_PROTOSW_ICSK flag is no need by smc,just remove it.After removing the INET_PROTOSW_ICSK flag, this patch alse revertcommit 6fd27ea183c2 ("net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC")to avoid casting smc_sock to inet_connection_sock.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68313 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add RDSEED fix for Zen5There's an issue with RDSEED's 16-bit and 32-bit register outputvariants on Zen5 which return a random value of 0 "at a rate inconsistentwith randomness while incorrectly signaling success (CF=1)". Search theweb for AMD-SB-7055 for more detail.Add a fix glue which checks microcode revisions. [ bp: Add microcode revisions checking, rewrite. ]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68347 Severity: Moderate CVSS3 score: 6.1

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: fix buffer overflow in hwdep read for DSP eventsThe DSP event handling code in hwdep_read() could write more bytes tothe user buffer than requested, when a user provides a buffer smallerthan the event header size (8 bytes).Fix by using min_t() to clamp the copy size, This ensures we never copymore than the user requested.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40292 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-net: fix received length check in big packetsSince commit 4959aebba8c0 ("virtio-net: use mtu size as buffer lengthfor big packets"), when guest gso is off, the allocated size for bigpackets is not MAX_SKB_FRAGS * PAGE_SIZE anymore but depends onnegotiated MTU. The number of allocated frags for big packets is storedin vi->big_packets_num_skbfrags.Because the host announced buffer length can be malicious (e.g. the hostvhost_net driver's get_rx_bufs is modified to announce incorrectlength), we need a check in virtio_net receive path. Currently, thecheck is not adapted to the new change which can lead to NULL pagepointer dereference in the below while loop when receiving length thatis larger than the allocated one.This commit fixes the received length check corresponding to the newchange.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68208 Severity: Moderate CVSS3 score: 6.0

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: account for current allocated stack depth in widen_imprecise_scalars()The usage pattern for widen_imprecise_scalars() looks as follows: prev_st = find_prev_entry(env, ...); queued_st = push_stack(...); widen_imprecise_scalars(env, prev_st, queued_st);Where prev_st is an ancestor of the queued_st in the explored statestree. This ancestor is not guaranteed to have same allocated stackdepth as queued_st. E.g. in the following case: def main(): for i in 1..2: foo(i) // same callsite, differnt param def foo(i): if i == 1: use 128 bytes of stack iterator based loopHere, for a second 'foo' call prev_st->allocated_stack is 128,while queued_st->allocated_stack is much smaller.widen_imprecise_scalars() needs to take this into account and avoidaccessing bpf_verifier_state->frame[*]->stack out of bounds.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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.7 (version in image is 15.7-150700.28.1).
cloud-init > 0-0 (version in image is 23.3-150100.8.85.4).

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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
gpg2 > 0-0 (version in image is 2.4.4-150600.3.12.1).

CVE-2026-0994 Severity: Moderate CVSS3 score: 5.9

Description: A denial-of-service (DoS) vulnerability exists in google.protobuf.json_format.ParseDict() in Python, where the max_recursion_depth limit can be bypassed when parsing nested google.protobuf.Any messages.Due to missing recursion depth accounting inside the internal Any-handling logic, an attacker can supply deeply nested Any structures that bypass the intended recursion limit, eventually exhausting Python's recursion stack and causing a RecursionError.

Packages affected:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311-protobuf < 4.25.1-150600.16.16.1 (version in image is 4.25.1-150600.16.13.1).

CVE-2023-54149 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:net: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addressesWhen using the felix driver (the only one which supports UC filteringand MC filtering) as a DSA master for a random other DSA switch, one cansee the following stack trace when the downstream switch ports join aVLAN-aware bridge:=============================WARNING: suspicious RCU usage-----------------------------net/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!stack backtrace:Workqueue: dsa_ordered dsa_slave_switchdev_event_workCall trace: lockdep_rcu_suspicious+0x170/0x210 vlan_for_each+0x8c/0x188 dsa_slave_sync_uc+0x128/0x178 __hw_addr_sync_dev+0x138/0x158 dsa_slave_set_rx_mode+0x58/0x70 __dev_set_rx_mode+0x88/0xa8 dev_uc_add+0x74/0xa0 dsa_port_bridge_host_fdb_add+0xec/0x180 dsa_slave_switchdev_event_work+0x7c/0x1c8 process_one_work+0x290/0x568What it's saying is that vlan_for_each() expects rtnl_lock() context andit's not getting it, when it's called from the DSA master's ndo_set_rx_mode().The caller of that - dsa_slave_set_rx_mode() - is the slave DSAinterface's dsa_port_bridge_host_fdb_add() which comes from the deferreddsa_slave_switchdev_event_work().We went to great lengths to avoid the rtnl_lock() context in that callpath in commit 0faf890fc519 ("net: dsa: drop rtnl_lock fromdsa_slave_switchdev_event_work"), and calling rtnl_lock() is simply notan option due to the possibility of deadlocking when callingdsa_flush_workqueue() from the call paths that do hold rtnl_lock() -basically all of them.So, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),the state of the 8021q driver on this device is really not protectedfrom concurrent access by anything.Looking at net/8021q/, I don't think that vlan_info->vid_list wasparticularly designed with RCU traversal in mind, so introducing an RCUread-side form of vlan_for_each() - vlan_for_each_rcu() - won't be soeasy, and it also wouldn't be exactly what we need anyway.In general I believe that the solution isn't in net/8021q/ anyway;vlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock()to be held per se - since it's not a netdev state change that we'reblocking, but rather, just concurrent additions/removals to a VLAN list.We don't even need sleepable context - the callback of vlan_for_each()just schedules deferred work.The proposed escape is to remove the dependency on vlan_for_each() andto open-code a non-sleepable, rtnl-free alternative to that, based oncopies of the VLAN list modified from .ndo_vlan_rx_add_vid() and.ndo_vlan_rx_kill_vid().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54201 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/efa: Fix wrong resources deallocation orderWhen trying to destroy QP or CQ, we first decrease the refcount andpotentially free memory regions allocated for the object and thenrequest the device to destroy the object. If the device fails, theobject isn't fully destroyed so the user/IB core can try to destroy theobject again which will lead to underflow when trying to decrease analready zeroed refcount.Deallocate resources in reverse order of allocating them to safely freethem.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54292 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/irdma: Fix data race on CQP request doneKCSAN detects a data race on cqp_request->request_done memory locationwhich is accessed locklessly in irdma_handle_cqp_op while beingupdated in irdma_cqp_ce_handler.Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid anycompiler optimizations like load fusing and/or KCSAN warning.[222808.417128] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma][222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:[222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma][222808.417725] cqp_compl_worker+0x1b/0x20 [irdma][222808.417827] process_one_work+0x4d1/0xa40[222808.417835] worker_thread+0x319/0x700[222808.417842] kthread+0x180/0x1b0[222808.417852] ret_from_fork+0x22/0x30[222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:[222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma][222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma][222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma][222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma][222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma][222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma][222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core][222808.418823] __ib_unregister_device+0xde/0x100 [ib_core][222808.418981] ib_unregister_device+0x22/0x40 [ib_core][222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma][222808.419248] i40iw_close+0x6f/0xc0 [irdma][222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e][222808.419450] i40iw_remove+0x21/0x30 [irdma][222808.419554] auxiliary_bus_remove+0x31/0x50[222808.419563] device_remove+0x69/0xb0[222808.419572] device_release_driver_internal+0x293/0x360[222808.419582] driver_detach+0x7c/0xf0[222808.419592] bus_remove_driver+0x8c/0x150[222808.419600] driver_unregister+0x45/0x70[222808.419610] auxiliary_driver_unregister+0x16/0x30[222808.419618] irdma_exit_module+0x18/0x1e [irdma][222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310[222808.419745] __x64_sys_delete_module+0x1b/0x30[222808.419755] do_syscall_64+0x39/0x90[222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd[222808.419829] value changed: 0x01 -> 0x03

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40340 Severity: Moderate CVSS3 score: 5.8

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe: Fix oops in xe_gem_fault when running core_hotunplug test.I saw an oops in xe_gem_fault when running the xe-fast-feedbacktestlist against the realtime kernel without debug options enabled.The panic happens after core_hotunplug unbind-rebind finishes.Presumably what happens is that a process mmaps, unlocks becauseof the FAULT_FLAG_RETRY_NOWAIT logic, has no process memory left,causing ttm_bo_vm_dummy_page() to return VM_FAULT_NOPAGE, sincethere was nothing left to populate, and then oopses in"mem_type_is_vram(tbo->resource->mem_type)" because tbo->resourceis NULL.It's convoluted, but fits the data and explains the oops afterthe test exits.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libabsl2401_0_0 < 20240116.3-150600.19.6.1 (version in image is 20240116.3-150600.19.3.15).

CVE-2023-53743 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:PCI: Free released resource after coalescingrelease_resource() doesn't actually free the resource or resource listentry so free the resource list entry to avoid a leak.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53750 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: freescale: Fix a memory out of bounds when num_configs is 1The config passed in by pad wakeup is 1, when num_configs is 1,Configuration [1] should not be fetched, which will be detectedby KASAN as a memory out of bounds condition. Modify to getconfigs[1] when num_configs is 2.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53752 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: deal with integer overflows in kmalloc_reserve()Blamed commit changed: ptr = kmalloc(size); if (ptr) size = ksize(ptr); size = kmalloc_size_roundup(size); ptr = kmalloc(size);This allowed various crash as reported by syzbot [1]and Kyle Zeng.Problem is that if @size is bigger than 0x80000001,kmalloc_size_roundup(size) returns 2^32.kmalloc_reserve() uses a 32bit variable (obj_size),so 2^32 is truncated to 0.kmalloc(0) returns ZERO_SIZE_PTR which is not handled byskb allocations.Following trace can be triggered if a netdev->mtu is setclose to 0x7fffffffWe might in the future limit netdev->mtu to more sensiblelimit (like KMALLOC_MAX_SIZE).This patch is based on a syzbot report, and also a reportand tentative fix from Kyle Zeng.[1]BUG: KASAN: user-memory-access in __build_skb_around net/core/skbuff.c:294 [inline]BUG: KASAN: user-memory-access in __alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527Write of size 32 at addr 00000000fffffd10 by task syz-executor.4/22554CPU: 1 PID: 22554 Comm: syz-executor.4 Not tainted 6.1.39-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023Call trace:dump_backtrace+0x1c8/0x1f4 arch/arm64/kernel/stacktrace.c:279show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:286__dump_stack lib/dump_stack.c:88 [inline]dump_stack_lvl+0x120/0x1a0 lib/dump_stack.c:106print_report+0xe4/0x4b4 mm/kasan/report.c:398kasan_report+0x150/0x1ac mm/kasan/report.c:495kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:189memset+0x40/0x70 mm/kasan/shadow.c:44__build_skb_around net/core/skbuff.c:294 [inline]__alloc_skb+0x3c4/0x6e8 net/core/skbuff.c:527alloc_skb include/linux/skbuff.h:1316 [inline]igmpv3_newpack+0x104/0x1088 net/ipv4/igmp.c:359add_grec+0x81c/0x1124 net/ipv4/igmp.c:534igmpv3_send_cr net/ipv4/igmp.c:667 [inline]igmp_ifc_timer_expire+0x1b0/0x1008 net/ipv4/igmp.c:810call_timer_fn+0x1c0/0x9f0 kernel/time/timer.c:1474expire_timers kernel/time/timer.c:1519 [inline]__run_timers+0x54c/0x710 kernel/time/timer.c:1790run_timer_softirq+0x28/0x4c kernel/time/timer.c:1803_stext+0x380/0xfbc____do_softirq+0x14/0x20 arch/arm64/kernel/irq.c:79call_on_irq_stack+0x24/0x4c arch/arm64/kernel/entry.S:891do_softirq_own_stack+0x20/0x2c arch/arm64/kernel/irq.c:84invoke_softirq kernel/softirq.c:437 [inline]__irq_exit_rcu+0x1c0/0x4cc kernel/softirq.c:683irq_exit_rcu+0x14/0x78 kernel/softirq.c:695el0_interrupt+0x7c/0x2e0 arch/arm64/kernel/entry-common.c:717__el0_irq_handler_common+0x18/0x24 arch/arm64/kernel/entry-common.c:724el0t_64_irq_handler+0x10/0x1c arch/arm64/kernel/entry-common.c:729el0t_64_irq+0x1a0/0x1a4 arch/arm64/kernel/entry.S:584

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53762 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Fix UAF in hci_disconnect_all_syncUse-after-free can occur in hci_disconnect_all_sync if a connection isdeleted by concurrent processing of a controller event.To prevent this the code now tries to iterate over the list backwardsto ensure the links are cleanup before its parents, also it no longerrelies on a cursor, instead it always uses the last element sincehci_abort_conn_sync is guaranteed to call hci_conn_del.UAF crash log:==================================================================BUG: KASAN: slab-use-after-free in hci_set_powered_sync(net/bluetooth/hci_sync.c:5424) [bluetooth]Read of size 8 at addr ffff888009d9c000 by task kworker/u9:0/124CPU: 0 PID: 124 Comm: kworker/u9:0 Tainted: G W6.5.0-rc1+ #10Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS1.16.2-1.fc38 04/01/2014Workqueue: hci0 hci_cmd_sync_work [bluetooth]Call Trace: dump_stack_lvl+0x5b/0x90 print_report+0xcf/0x670 ? __virt_addr_valid+0xdd/0x160 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] kasan_report+0xa6/0xe0 ? hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_set_powered_sync+0x2c9/0x4a0 [bluetooth] ? __pfx_hci_set_powered_sync+0x10/0x10 [bluetooth] ? __pfx_lock_release+0x10/0x10 ? __pfx_set_powered_sync+0x10/0x10 [bluetooth] hci_cmd_sync_work+0x137/0x220 [bluetooth] process_one_work+0x526/0x9d0 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? mark_held_locks+0x1a/0x90 worker_thread+0x92/0x630 ? __pfx_worker_thread+0x10/0x10 kthread+0x196/0x1e0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2c/0x50 Allocated by task 1782: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 __kasan_kmalloc+0x8f/0xa0 hci_conn_add+0xa5/0xa80 [bluetooth] hci_bind_cis+0x881/0x9b0 [bluetooth] iso_connect_cis+0x121/0x520 [bluetooth] iso_sock_connect+0x3f6/0x790 [bluetooth] __sys_connect+0x109/0x130 __x64_sys_connect+0x40/0x50 do_syscall_64+0x60/0x90 entry_SYSCALL_64_after_hwframe+0x6e/0xd8Freed by task 695: kasan_save_stack+0x33/0x60 kasan_set_track+0x25/0x30 kasan_save_free_info+0x2b/0x50 __kasan_slab_free+0x10a/0x180 __kmem_cache_free+0x14d/0x2e0 device_release+0x5d/0xf0 kobject_put+0xdf/0x270 hci_disconn_complete_evt+0x274/0x3a0 [bluetooth] hci_event_packet+0x579/0x7e0 [bluetooth] hci_rx_work+0x287/0xaa0 [bluetooth] process_one_work+0x526/0x9d0 worker_thread+0x92/0x630 kthread+0x196/0x1e0 ret_from_fork+0x2c/0x50==================================================================

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53768 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regmap-irq: Fix out-of-bounds access when allocating config buffersWhen allocating the 2D array for handling IRQ type registers inregmap_add_irq_chip_fwnode(), the intent is to allocate a matrixwith num_config_bases rows and num_config_regs columns.This is currently handled by allocating a buffer to hold a pointer foreach row (i.e. num_config_bases). After that, the logic attempts toallocate the memory required to hold the register configuration foreach row. However, instead of doing this allocation for each row(i.e. num_config_bases allocations), the logic erroneously does thisallocation num_config_regs number of times.This scenario can lead to out-of-bounds accesses when num_config_regsis greater than num_config_bases. Fix this by updating the terminatingcondition of the loop that allocates the memory for holding the registerconfiguration to allocate memory only for each row in the matrix.Amit Pundir reported a crash that was occurring on his db845c devicedue to memory corruption (see "Closes" tag for Amit's report). The KASANreport below helped narrow it down to this issue:[ 14.033877][ T1] ==================================================================[ 14.042507][ T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364[ 14.050796][ T1] Write of size 8 at addr 06ffff8081021850 by task init/1[ 14.242004][ T1] The buggy address belongs to the object at ffffff8081021850[ 14.242004][ T1] which belongs to the cache kmalloc-8 of size 8[ 14.255669][ T1] The buggy address is located 0 bytes inside of[ 14.255669][ T1] 8-byte region [ffffff8081021850, ffffff8081021858)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53778 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:accel/qaic: Clean up integer overflow checking in map_user_pages()The encode_dma() function has some validation on in_trans->size but itwould be more clear to move those checks to find_and_map_user_pages().The encode_dma() had two checks: if (in_trans->addr + in_trans->size < in_trans->addr || !in_trans->size) return -EINVAL;The in_trans->addr variable is the starting address. The in_trans->sizevariable is the total size of the transfer. The transfer can occur inparts and the resources->xferred_dma_size tracks how many bytes we havealready transferred.This patch introduces a new variable "remaining" which represents theamount we want to transfer (in_trans->size) minus the amount we havealready transferred (resources->xferred_dma_size).I have modified the check for if in_trans->size is zero to instead checkif in_trans->size is less than resources->xferred_dma_size. If we havealready transferred more bytes than in_trans->size then there are negativebytes remaining which doesn't make sense. If there are zero bytesremaining to be copied, just return success.The check in encode_dma() checked that "addr + size" could not overflowand barring a driver bug that should work, but it's easier to check ifwe do this in parts. First check that "in_trans->addr +resources->xferred_dma_size" is safe. Then check that "xfer_start_addr +remaining" is safe.My final concern was that we are dealing with u64 values but on 32bitsystems the kmalloc() function will truncate the sizes to 32 bits. SoI calculated "total = in_trans->size + offset_in_page(xfer_start_addr);"and returned -EINVAL if it were >= SIZE_MAX. This will not affect 64bitsystems.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53784 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm: bridge: dw_hdmi: fix connector access for scdcCommit 5d844091f237 ("drm/scdc-helper: Pimp SCDC debugs") changed the scdcinterface to pick up an i2c adapter from a connector instead. However, inthe case of dw-hdmi, the wrong connector was being used to pass i2c adapterinformation, since dw-hdmi's embedded connector structure is only populatedwhen the bridge attachment callback explicitly asks for it.drm-meson is handling connector creation, so this won't happen, leading toa NULL pointer dereference.Fix it by having scdc functions access dw-hdmi's current connector pointerinstead, which is assigned during the bridge enablement stage.[narmstrong: moved Fixes tag before first S-o-b and added Reported-by tag]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53787 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:regulator: da9063: fix null pointer deref with partial DT configWhen some of the da9063 regulators do not have corresponding DT nodesa null pointer dereference occurs on boot because such regulators haveno init_data causing the pointers calculated inda9063_check_xvp_constraints() to be invalid.Do not dereference them in this case.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53791 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md: fix warning for holder mismatch from export_rdev()Commit a1d767191096 ("md: use mddev->external to select holder inexport_rdev()") fix the problem that 'claim_rdev' is used forblkdev_get_by_dev() while 'rdev' is used for blkdev_put().However, if mddev->external is changed from 0 to 1, then 'rdev' is usedfor blkdev_get_by_dev() while 'claim_rdev' is used for blkdev_put(). Andthis problem can be reporduced reliably by following:New file: mdadm/tests/23rdev-lifetimedevname=${dev0##*/}devt=`cat /sys/block/$devname/dev`pid=""runtime=2clean_up_test() { pill -9 $pid echo clear > /sys/block/md0/md/array_state}trap 'clean_up_test' EXITadd_by_sysfs() { while true; do echo $devt > /sys/block/md0/md/new_dev done}remove_by_sysfs(){ while true; do echo remove > /sys/block/md0/md/dev-${devname}/state done}echo md0 > /sys/module/md_mod/parameters/new_array || die "create md0 failed"add_by_sysfs &pid="$pid $!"remove_by_sysfs &pid="$pid $!"sleep $runtimeexit 0Test cmd:./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetimeTest result:------------[ cut here ]------------WARNING: CPU: 0 PID: 960 at block/bdev.c:618 blkdev_put+0x27c/0x330Modules linked in: multipath md_mod loopCPU: 0 PID: 960 Comm: test Not tainted 6.5.0-rc2-00121-g01e55c376936-dirty #50RIP: 0010:blkdev_put+0x27c/0x330Call Trace: export_rdev.isra.23+0x50/0xa0 [md_mod] mddev_unlock+0x19d/0x300 [md_mod] rdev_attr_store+0xec/0x190 [md_mod] sysfs_kf_write+0x52/0x70 kernfs_fop_write_iter+0x19a/0x2a0 vfs_write+0x3b5/0x770 ksys_write+0x74/0x150 __x64_sys_write+0x22/0x30 do_syscall_64+0x40/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcdFix the problem by recording if 'rdev' is used as holder.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53792 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-core: fix memory leak in dhchap_ctrl_secretFree dhchap_secret in nvme_ctrl_dhchap_ctrl_secret_store() before wereturn when nvme_auth_generate_key() returns error.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53793 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf tool x86: Fix perf_env memory leakFound by leak sanitizer:```==1632594==ERROR: LeakSanitizer: detected memory leaksDirect leak of 21 byte(s) in 1 object(s) allocated from: #0 0x7f2953a7077b in __interceptor_strdup ../../../../src/libsanitizer/asan/asan_interceptors.cpp:439 #1 0x556701d6fbbf in perf_env__read_cpuid util/env.c:369 #2 0x556701d70589 in perf_env__cpuid util/env.c:465 #3 0x55670204bba2 in x86__is_amd_cpu arch/x86/util/env.c:14 #4 0x5567020487a2 in arch__post_evsel_config arch/x86/util/evsel.c:83 #5 0x556701d8f78b in evsel__config util/evsel.c:1366 #6 0x556701ef5872 in evlist__config util/record.c:108 #7 0x556701cd6bcd in test__PERF_RECORD tests/perf-record.c:112 #8 0x556701cacd07 in run_test tests/builtin-test.c:236 #9 0x556701cacfac in test_and_print tests/builtin-test.c:265 #10 0x556701cadddb in __cmd_test tests/builtin-test.c:402 #11 0x556701caf2aa in cmd_test tests/builtin-test.c:559 #12 0x556701d3b557 in run_builtin tools/perf/perf.c:323 #13 0x556701d3bac8 in handle_internal_command tools/perf/perf.c:377 #14 0x556701d3be90 in run_argv tools/perf/perf.c:421 #15 0x556701d3c3f8 in main tools/perf/perf.c:537 #16 0x7f2952a46189 in __libc_start_call_main ../sysdeps/nptl/libc_start_call_main.h:58SUMMARY: AddressSanitizer: 21 byte(s) leaked in 1 allocation(s).```

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53795 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: IOMMUFD_DESTROY should not increase the refcountsyzkaller found a race where IOMMUFD_DESTROY increments the refcount: obj = iommufd_get_object(ucmd->ictx, cmd->id, IOMMUFD_OBJ_ANY); if (IS_ERR(obj)) return PTR_ERR(obj); iommufd_ref_to_users(obj); /* See iommufd_ref_to_users() */ if (!iommufd_object_destroy_user(ucmd->ictx, obj))As part of the sequence to join the two existing primitives together.Allowing the refcount the be elevated without holding the destroy_rwsemviolates the assumption that all temporary refcount elevations areprotected by destroy_rwsem. Racing IOMMUFD_DESTROY withiommufd_object_destroy_user() will cause spurious failures: WARNING: CPU: 0 PID: 3076 at drivers/iommu/iommufd/device.c:477 iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:478 Modules linked in: CPU: 0 PID: 3076 Comm: syz-executor.0 Not tainted 6.3.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/03/2023 RIP: 0010:iommufd_access_destroy+0x18/0x20 drivers/iommu/iommufd/device.c:477 Code: e8 3d 4e 00 00 84 c0 74 01 c3 0f 0b c3 0f 1f 44 00 00 f3 0f 1e fa 48 89 fe 48 8b bf a8 00 00 00 e8 1d 4e 00 00 84 c0 74 01 c3 <0f> 0b c3 0f 1f 44 00 00 41 57 41 56 41 55 4c 8d ae d0 00 00 00 41 RSP: 0018:ffffc90003067e08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888109ea0300 RCX: 0000000000000000 RDX: 0000000000000001 RSI: 0000000000000000 RDI: 00000000ffffffff RBP: 0000000000000004 R08: 0000000000000000 R09: ffff88810bbb3500 R10: ffff88810bbb3e48 R11: 0000000000000000 R12: ffffc90003067e88 R13: ffffc90003067ea8 R14: ffff888101249800 R15: 00000000fffffffe FS: 00007ff7254fe6c0(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000555557262da8 CR3: 000000010a6fd000 CR4: 0000000000350ef0 Call Trace: iommufd_test_create_access drivers/iommu/iommufd/selftest.c:596 [inline] iommufd_test+0x71c/0xcf0 drivers/iommu/iommufd/selftest.c:813 iommufd_fops_ioctl+0x10f/0x1b0 drivers/iommu/iommufd/main.c:337 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+0x84/0xc0 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x38/0x80 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcdThe solution is to not increment the refcount on the IOMMUFD_DESTROY pathat all. Instead use the xa_lock to serialize everything. The refcountcheck == 1 and xa_erase can be done under a single critical region. Thisavoids the need for any refcount incrementing.It has the downside that if userspace races destroy with other operationsit will get an EBUSY instead of waiting, but this is kind of racing isalready dangerous.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53797 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:HID: wacom: Use ktime_t rather than int when dealing with timestampsCode which interacts with timestamps needs to use the ktime_t typereturned by functions like ktime_get. The int type does not offerenough space to store these values, and attempting to use it is arecipe for problems. In this particular case, overflows would occurwhen calculating/storing timestamps leading to incorrect values beingreported to userspace. In some cases these bad timestamps cause inputhandling in userspace to appear hung.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53808 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: fix memory leak in mwifiex_histogram_read()Always free the zeroed page on return from 'mwifiex_histogram_read()'.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53813 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix rbtree traversal bug in ext4_mb_use_preallocatedDuring allocations, while looking for preallocations(PA) in the perinode rbtree, we can't do a direct traversal of the tree becauseext4_mb_discard_group_preallocation() can paralelly mark the pa deletedand that can cause direct traversal to skip some entries. This wasleading to a BUG_ON() being hit [1] when we missed a PA that could satisfyour request and ultimately tried to create a new PA that would overlapwith the missed one.To makes sure we handle that case while still keeping the performance ofthe rbtree, we make use of the fact that the only pa that could possiblyoverlap the original goal start is the one that satisfies the belowconditions: 1. It must have it's logical start immediately to the left of (ie less than) original logical start. 2. It must not be deletedTo find this pa we use the following traversal method:1. Descend into the rbtree normally to find the immediate neighboringPA. Here we keep descending irrespective of if the PA is deleted or ifit overlaps with our request etc. The goal is to find an immediatelyadjacent PA.2. If the found PA is on right of original goal, use rb_prev() to findthe left adjacent PA.3. Check if this PA is deleted and keep moving left with rb_prev() untila non deleted PA is found.4. This is the PA we are looking for. Now we can check if it can satisfythe original request and proceed accordingly.This approach also takes care of having deleted PAs in the tree.(While we are at it, also fix a possible overflow bug in calculating theend of a PA)[1] https://lore.kernel.org/linux-ext4/CA+G9fYv2FRpLqBZf34ZinR8bU2_ZRAUOjKAD3+tKRFaEQHtt8Q@mail.gmail.com/

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53819 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:amdgpu: validate offset_in_bo of drm_amdgpu_gem_vaThis is motivated by OOB access in amdgpu_vm_update_range whenoffset_in_bo+map_size overflows.v2: keep the validations in amdgpu_vm_bo_mapv3: add the validations to amdgpu_vm_bo_map/amdgpu_vm_bo_replace_map rather than to amdgpu_gem_va_ioctl

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53821 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ip6_vti: fix slab-use-after-free in decode_session6When ipv6_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 ipv6_vti 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 ffff88802e08edc2 by task swapper/0/0CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.4.0-next-20230707-00001-g84e2cad7f979 #410Hardware 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/0xb0vti6_tnl_xmit+0x3e6/0x1ee0dev_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/0xc0Allocated by task 9176: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/0x330netlink_sendmsg+0x9b1/0xe30sock_sendmsg+0xde/0x190____sys_sendmsg+0x739/0x920___sys_sendmsg+0x110/0x1b0__sys_sendmsg+0xf7/0x1c0do_syscall_64+0x39/0xb0entry_SYSCALL_64_after_hwframe+0x63/0xcdFreed by task 9176:kasan_save_stack+0x22/0x40kasan_set_track+0x25/0x30kasan_save_free_info+0x2b/0x40____kasan_slab_free+0x160/0x1c0slab_free_freelist_hook+0x11b/0x220kmem_cache_free+0xf0/0x490skb_free_head+0x17f/0x1b0skb_release_data+0x59c/0x850consume_skb+0xd2/0x170netlink_unicast+0x54f/0x7f0netlink_sendmsg+0x926/0xe30sock_sendmsg+0xde/0x190____sys_sendmsg+0x739/0x920___sys_sendmsg+0x110/0x1b0__sys_sendmsg+0xf7/0x1c0do_syscall_64+0x39/0xb0entry_SYSCALL_64_after_hwframe+0x63/0xcdThe buggy address belongs to the object at ffff88802e08ed00which belongs to the cache skbuff_small_head of size 640The buggy address is located 194 bytes inside offreed 640-byte region [ffff88802e08ed00, ffff88802e08ef80)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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53823 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:block/rq_qos: protect rq_qos apis with a new lockcommit 50e34d78815e ("block: disable the elevator int del_gendisk")move rq_qos_exit() from disk_release() to del_gendisk(), this willintroduce some problems:1) If rq_qos_add() is triggered by enabling iocost/iolatency through cgroupfs, then it can concurrent with del_gendisk(), it's not safe to write 'q->rq_qos' concurrently.2) Activate cgroup policy that is relied on rq_qos will call rq_qos_add() and blkcg_activate_policy(), and if rq_qos_exit() is called in the middle, null-ptr-dereference will be triggered in blkcg_activate_policy().3) blkg_conf_open_bdev() can call blkdev_get_no_open() first to find the disk, then if rq_qos_exit() from del_gendisk() is done before rq_qos_add(), then memory will be leaked.This patch add a new disk level mutex 'rq_qos_mutex':1) The lock will protect rq_qos_exit() directly.2) For wbt that doesn't relied on blk-cgroup, rq_qos_add() can only be called from disk initialization for now because wbt can't be destructed until rq_qos_exit(), so it's safe not to protect wbt for now. Hoever, in case that rq_qos dynamically destruction is supported in the furture, this patch also protect rq_qos_add() from wbt_init() directly, this is enough because blk-sysfs already synchronize writers with disk removal.3) For iocost and iolatency, in order to synchronize disk removal and cgroup configuration, the lock is held after blkdev_get_no_open() from blkg_conf_open_bdev(), and is released in blkg_conf_exit(). In order to fix the above memory leak, disk_live() is checked after holding the new lock.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53828 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: Avoid use-after-free in dbg for hci_add_adv_monitor()KSAN reports use-after-free in hci_add_adv_monitor().While adding an adv monitor, hci_add_adv_monitor() calls -> msft_add_monitor_pattern() calls -> msft_add_monitor_sync() calls -> msft_le_monitor_advertisement_cb() calls in an error case -> hci_free_adv_monitor() which frees the *moniter.This is referenced by bt_dev_dbg() in hci_add_adv_monitor().Fix the bt_dev_dbg() by using handle instead of monitor->handle.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53834 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: adc: ina2xx: avoid NULL pointer dereference on OF device matchThe affected lines were resulting in a NULL pointer dereference on ourplatform because the device tree contained the following list ofcompatible strings: power-sensor@40 { compatible = "ti,ina232", "ti,ina231"; ... };Since the driver doesn't declare a compatible string "ti,ina232", the OFmatching succeeds on "ti,ina231". But the I2C device ID info ispopulated via the first compatible string, cf. modalias population inof_i2c_get_board_info(). Since there is no "ina232" entry in the legacyI2C device ID table either, the struct i2c_device_id *id pointer in theprobe function is NULL.Fix this by using the already populated type variable instead, whichpoints to the proper driver data. Since the name is also wanted, add ageneric one to the ina2xx_config table.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53839 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dccp: fix data-race around dp->dccps_mss_cachedccp_sendmsg() reads dp->dccps_mss_cache before locking the socket.Same thing in do_dccp_getsockopt().Add READ_ONCE()/WRITE_ONCE() annotations,and change dccp_sendmsg() to check again dccps_mss_cacheafter socket is locked.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53842 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: codecs: wcd-mbhc-v2: fix resource leaks on component removeThe MBHC resources must be released on component probe failure andremoval so can not be tied to the lifetime of the component device.This is specifically needed to allow probe deferrals of the sound cardwhich otherwise fails when reprobing the codec component: snd-sc8280xp sound: ASoC: failed to instantiate card -517 genirq: Flags mismatch irq 299. 00002001 (mbhc sw intr) vs. 00002001 (mbhc sw intr) wcd938x_codec audio-codec: Failed to request mbhc interrupts -16 wcd938x_codec audio-codec: mbhc initialization failed wcd938x_codec audio-codec: ASoC: error at snd_soc_component_probe on audio-codec: -16 snd-sc8280xp sound: ASoC: failed to instantiate card -16

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53843 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: reject negative ifindexRecent changes in net-next (commit 759ab1edb56c ("net: store netdevsin an xarray")) refactored the handling of pre-assigned ifindexesand let syzbot surface a latent problem in ovs. ovs does not validateifindex, making it possible to create netdev ports with negativeifindex values. It's easy to repro with YNL:$ ./cli.py --spec netlink/specs/ovs_datapath.yaml \ --do new \ --json '{"upcall-pid": 1, "name":"my-dp"}'$ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'$ ip link show-65536: some-port0: mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000 link/ether 7a:48:21:ad:0b:fb brd ff:ff:ff:ff:ff:ff...Validate the inputs. Now the second command correctly returns:$ ./cli.py --spec netlink/specs/ovs_vport.yaml \ --do new \ --json '{"upcall-pid": "00000001", "name": "some-port0", "dp-ifindex":3,"ifindex":4294901760,"type":2}'lib.ynl.NlError: Netlink error: Numerical result out of rangenl_len = 108 (92) nl_flags = 0x300 nl_type = 2 error: -34 extack: {'msg': 'integer out of range', 'unknown': [[type:4 len:36] b'\x0c\x00\x02\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0c\x00\x03\x00\xff\xff\xff\x7f\x00\x00\x00\x00\x08\x00\x01\x00\x08\x00\x00\x00'], 'bad-attr': '.ifindex'}Accept 0 since it used to be silently ignored.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53844 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/ttm: Don't leak a resource on swapout move errorIf moving the bo to system for swapout failed, we were leakinga resource. Fix.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53847 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Fix uninit-value in alauda_check_media()Syzbot got KMSAN to complain about access to an uninitialized value inthe alauda subdriver of usb-storage:BUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0drivers/usb/storage/alauda.c:1137CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOSGoogle 01/01/2011Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x191/0x1f0 lib/dump_stack.c:113 kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108 __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250 alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460The problem is that alauda_check_media() doesn't verify that its USBtransfer succeeded before trying to use the received data. Whatshould happen if the transfer fails isn't entirely clear, but areasonably conservative approach is to pretend that no media ispresent.A similar problem exists in a usb_stor_dbg() call inalauda_get_media_status(). In this case, when an error occurs thecall is redundant, because usb_stor_ctrl_transfer() already will printa debugging message.Finally, unrelated to the uninitialized memory access, is the factthat alauda_check_media() performs DMA to a buffer on the stack.Fortunately usb-storage provides a general purpose DMA-able buffer foruses like this. We'll use it instead.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53848 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:md/raid5-cache: fix a deadlock in r5l_exit_log()Commit b13015af94cf ("md/raid5-cache: Clear conf->log after finishingwork") introduce a new problem:// caller hold reconfig_mutexr5l_exit_log flush_work(&log->disable_writeback_work) r5c_disable_writeback_async wait_event /* * conf->log is not NULL, and mddev_trylock() * will fail, wait_event() can never pass. */ conf->log = NULLFix this problem by setting 'config->log' to NULL before wake_up() as itused to be, so that wait_event() from r5c_disable_writeback_async() canexist. In the meantime, move forward md_unregister_thread() so thatnull-ptr-deref this commit fixed can still be fixed.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53850 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iavf: use internal state to free traffic IRQsIf the system tries to close the netdev while iavf_reset_task() isrunning, __LINK_STATE_START will be cleared and netif_running() willreturn false in iavf_reinit_interrupt_scheme(). This will result iniavf_free_traffic_irqs() not being called and a leak as follows: [7632.489326] remove_proc_entry: removing non-empty directory 'irq/999', leaking at least 'iavf-enp24s0f0v0-TxRx-0' [7632.490214] WARNING: CPU: 0 PID: 10 at fs/proc/generic.c:718 remove_proc_entry+0x19b/0x1b0is shown when pci_disable_msix() is later called. Fix by using theinternal adapter state. The traffic IRQs will always exist ifstate == __IAVF_RUNNING.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53851 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/msm/dp: Drop aux devices together with DP controllerUsing devres to depopulate the aux bus made sure that upon a probedeferral the EDP panel device would be destroyed and recreated upon nextattempt.But the struct device which the devres is tied to is the DPUs(drm_dev->dev), which may be happen after the DP controller is torndown.Indications of this can be seen in the commonly seen EDID-hexdump fullof zeros in the log, or the occasional/rare KASAN fault where thepanel's attempt to read the EDID information causes a use after free onDP resources.It's tempting to move the devres to the DP controller's struct device,but the resources used by the device(s) on the aux bus are explicitlytorn down in the error path. The KASAN-reported use-after-free alsoremains, as the DP aux "module" explicitly frees its devres-allocatedmemory in this code path.As such, explicitly depopulate the aux bus in the error path, and in thecomponent unbind path, to avoid these issues.Patchwork: https://patchwork.freedesktop.org/patch/542163/

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53852 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-core: fix memory leak in dhchap_secret_storeFree dhchap_secret in nvme_ctrl_dhchap_secret_store() before we returnfix following kmemleack:-unreferenced object 0xffff8886376ea800 (size 64): comm "check", pid 22048, jiffies 4344316705 (age 92.199s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL backtrace: [<0000000030ce5d4b>] __kmalloc+0x4b/0x130 [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core] [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0 [<00000000437e7ced>] vfs_write+0x2ba/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdcunreferenced object 0xffff8886376eaf00 (size 64): comm "check", pid 22048, jiffies 4344316736 (age 92.168s) hex dump (first 32 bytes): 44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67 DHHC-1:00:nxr5Kg 75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c uX4uoAxsJa4c/huL backtrace: [<0000000030ce5d4b>] __kmalloc+0x4b/0x130 [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core] [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0 [<00000000437e7ced>] vfs_write+0x2ba/0x3c0 [<00000000f9491baf>] ksys_write+0x5f/0xe0 [<000000001c46513d>] do_syscall_64+0x3b/0x90 [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53857 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: bpf_sk_storage: Fix invalid wait context lockdep report'./test_progs -t test_local_storage' reported a splat:[ 27.137569] =============================[ 27.138122] [ BUG: Invalid wait context ][ 27.138650] 6.5.0-03980-gd11ae1b16b0a #247 Tainted: G O[ 27.139542] -----------------------------[ 27.140106] test_progs/1729 is trying to lock:[ 27.140713] ffff8883ef047b88 (stock_lock){-.-.}-{3:3}, at: local_lock_acquire+0x9/0x130[ 27.141834] other info that might help us debug this:[ 27.142437] context-{5:5}[ 27.142856] 2 locks held by test_progs/1729:[ 27.143352] #0: ffffffff84bcd9c0 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x40[ 27.144492] #1: ffff888107deb2c0 (&storage->lock){..-.}-{2:2}, at: bpf_local_storage_update+0x39e/0x8e0[ 27.145855] stack backtrace:[ 27.146274] CPU: 0 PID: 1729 Comm: test_progs Tainted: G O 6.5.0-03980-gd11ae1b16b0a #247[ 27.147550] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014[ 27.149127] Call Trace:[ 27.149490] [ 27.149867] dump_stack_lvl+0x130/0x1d0[ 27.152609] dump_stack+0x14/0x20[ 27.153131] __lock_acquire+0x1657/0x2220[ 27.153677] lock_acquire+0x1b8/0x510[ 27.157908] local_lock_acquire+0x29/0x130[ 27.159048] obj_cgroup_charge+0xf4/0x3c0[ 27.160794] slab_pre_alloc_hook+0x28e/0x2b0[ 27.161931] __kmem_cache_alloc_node+0x51/0x210[ 27.163557] __kmalloc+0xaa/0x210[ 27.164593] bpf_map_kzalloc+0xbc/0x170[ 27.165147] bpf_selem_alloc+0x130/0x510[ 27.166295] bpf_local_storage_update+0x5aa/0x8e0[ 27.167042] bpf_fd_sk_storage_update_elem+0xdb/0x1a0[ 27.169199] bpf_map_update_value+0x415/0x4f0[ 27.169871] map_update_elem+0x413/0x550[ 27.170330] __sys_bpf+0x5e9/0x640[ 27.174065] __x64_sys_bpf+0x80/0x90[ 27.174568] do_syscall_64+0x48/0xa0[ 27.175201] entry_SYSCALL_64_after_hwframe+0x6e/0xd8[ 27.175932] RIP: 0033:0x7effb40e41ad[ 27.176357] Code: 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 0d8[ 27.179028] RSP: 002b:00007ffe64c21fc8 EFLAGS: 00000202 ORIG_RAX: 0000000000000141[ 27.180088] RAX: ffffffffffffffda RBX: 00007ffe64c22768 RCX: 00007effb40e41ad[ 27.181082] RDX: 0000000000000020 RSI: 00007ffe64c22008 RDI: 0000000000000002[ 27.182030] RBP: 00007ffe64c21ff0 R08: 0000000000000000 R09: 00007ffe64c22788[ 27.183038] R10: 0000000000000064 R11: 0000000000000202 R12: 0000000000000000[ 27.184006] R13: 00007ffe64c22788 R14: 00007effb42a1000 R15: 0000000000000000[ 27.184958] It complains about acquiring a local_lock while holding a raw_spin_lock.It means it should not allocate memory while holding a raw_spin_locksince it is not safe for RT.raw_spin_lock is needed because bpf_local_storage supports tracingcontext. In particular for task local storage, it is easy toget a "current" task PTR_TO_BTF_ID in tracing bpf prog.However, task (and cgroup) local storage has already been moved tobpf mem allocator which can be used after raw_spin_lock.The splat is for the sk storage. For sk (and inode) storage,it has not been moved to bpf mem allocator. Using raw_spin_lock or not,kzalloc(GFP_ATOMIC) could theoretically be unsafe in tracing context.However, the local storage helper requires a verifier acceptedsk pointer (PTR_TO_BTF_ID), it is hypothetical if that (mean runninga bpf prog in a kzalloc unsafe context and also able to hold a verifieraccepted sk pointer) could happen.This patch avoids kzalloc after raw_spin_lock to silent the splat.There is an existing kzalloc before the raw_spin_lock. At that point,a kzalloc is very likely required because a lookup has just been donebefore. Thus, this patch always does the kzalloc before acq---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53858 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tty: serial: samsung_tty: Fix a memory leak in s3c24xx_serial_getclk() in case of errorIf clk_get_rate() fails, the clk that has just been allocated needs to befreed.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53860 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:dm: don't attempt to queue IO under RCU protectiondm looks up the table for IO based on the request type, with anassumption that if the request is marked REQ_NOWAIT, it's fine toattempt to submit that IO while under RCU read lock protection. Thisis not OK, as REQ_NOWAIT just means that we should not be sleepingwaiting on other IO, it does not mean that we can't potentiallyschedule.A simple test case demonstrates this quite nicely:int main(int argc, char *argv[]){ struct iovec iov; int fd; fd = open("/dev/dm-0", O_RDONLY | O_DIRECT); posix_memalign(&iov.iov_base, 4096, 4096); iov.iov_len = 4096; preadv2(fd, &iov, 1, 0, RWF_NOWAIT); return 0;}which will instantly spew:BUG: sleeping function called from invalid context at include/linux/sched/mm.h:306in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 5580, name: dm-nowaitpreempt_count: 0, expected: 0RCU nest depth: 1, expected: 0INFO: lockdep is turned off.CPU: 7 PID: 5580 Comm: dm-nowait Not tainted 6.6.0-rc1-g39956d2dcd81 #132Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call Trace: dump_stack_lvl+0x11d/0x1b0 __might_resched+0x3c3/0x5e0 ? preempt_count_sub+0x150/0x150 mempool_alloc+0x1e2/0x390 ? mempool_resize+0x7d0/0x7d0 ? lock_sync+0x190/0x190 ? lock_release+0x4b7/0x670 ? internal_get_user_pages_fast+0x868/0x2d40 bio_alloc_bioset+0x417/0x8c0 ? bvec_alloc+0x200/0x200 ? internal_get_user_pages_fast+0xb8c/0x2d40 bio_alloc_clone+0x53/0x100 dm_submit_bio+0x27f/0x1a20 ? lock_release+0x4b7/0x670 ? blk_try_enter_queue+0x1a0/0x4d0 ? dm_dax_direct_access+0x260/0x260 ? rcu_is_watching+0x12/0xb0 ? blk_try_enter_queue+0x1cc/0x4d0 __submit_bio+0x239/0x310 ? __bio_queue_enter+0x700/0x700 ? kvm_clock_get_cycles+0x40/0x60 ? ktime_get+0x285/0x470 submit_bio_noacct_nocheck+0x4d9/0xb80 ? should_fail_request+0x80/0x80 ? preempt_count_sub+0x150/0x150 ? lock_release+0x4b7/0x670 ? __bio_add_page+0x143/0x2d0 ? iov_iter_revert+0x27/0x360 submit_bio_noacct+0x53e/0x1b30 submit_bio_wait+0x10a/0x230 ? submit_bio_wait_endio+0x40/0x40 __blkdev_direct_IO_simple+0x4f8/0x780 ? blkdev_bio_end_io+0x4c0/0x4c0 ? stack_trace_save+0x90/0xc0 ? __bio_clone+0x3c0/0x3c0 ? lock_release+0x4b7/0x670 ? lock_sync+0x190/0x190 ? atime_needs_update+0x3bf/0x7e0 ? timestamp_truncate+0x21b/0x2d0 ? inode_owner_or_capable+0x240/0x240 blkdev_direct_IO.part.0+0x84a/0x1810 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 ? blkdev_read_iter+0x40d/0x530 ? reacquire_held_locks+0x4e0/0x4e0 ? __blkdev_direct_IO_simple+0x780/0x780 ? rcu_is_watching+0x12/0xb0 ? __mark_inode_dirty+0x297/0xd50 ? preempt_count_add+0x72/0x140 blkdev_read_iter+0x2a4/0x530 do_iter_readv_writev+0x2f2/0x3c0 ? generic_copy_file_range+0x1d0/0x1d0 ? fsnotify_perm.part.0+0x25d/0x630 ? security_file_permission+0xd8/0x100 do_iter_read+0x31b/0x880 ? import_iovec+0x10b/0x140 vfs_readv+0x12d/0x1a0 ? vfs_iter_read+0xb0/0xb0 ? rcu_is_watching+0x12/0xb0 ? rcu_is_watching+0x12/0xb0 ? lock_release+0x4b7/0x670 do_preadv+0x1b3/0x260 ? do_readv+0x370/0x370 __x64_sys_preadv2+0xef/0x150 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7f5af41ad806Code: 41 54 41 89 fc 55 44 89 c5 53 48 89 cb 48 83 ec 18 80 3d e4 dd 0d 00 00 74 7a 45 89 c1 49 89 ca 45 31 c0 b8 47 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 be 00 00 00 48 85 c0 79 4a 48 8b 0d da 55RSP: 002b:00007ffd3145c7f0 EFLAGS: 00000246 ORIG_RAX: 0000000000000147RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5af41ad806RDX: 0000000000000001 RSI: 00007ffd3145c850 RDI: 0000000000000003RBP: 0000000000000008 R08: 0000000000000000 R09: 0000000000000008R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000003R13: 00007ffd3145c850 R14: 000055f5f0431dd8 R15: 0000000000000001 where in fact it is---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53861 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: correct grp validation in ext4_mb_good_groupGroup corruption check will access memory of grp and will trigger kernelcrash if grp is NULL. So do NULL check before corruption check.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53864 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()When disabling overlay plane in mxsfb_plane_overlay_atomic_update(),overlay plane's framebuffer pointer is NULL. So, dereferencing it wouldcause a kernel Oops(NULL pointer dereferencing). Fix the issue bydisabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53996 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/sev: Make enc_dec_hypercall() accept a size instead of npagesenc_dec_hypercall() accepted a page count instead of a size, whichforced its callers to round up. As a result, non-page alignedvaddrs caused pages to be spuriously marked as decrypted via theencryption status hypercall, which in turn caused consistentcorruption of pages during live migration. Live migration requiresaccurate encryption status information to avoid migrating pagesfrom the wrong perspective.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53997 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:thermal: of: fix double-free on unregistrationSince commit 3d439b1a2ad3 ("thermal/core: Alloc-copy-free the thermalzone parameters structure"), thermal_zone_device_register() allocatesa copy of the tzp argument and frees it when unregistering, sothermal_of_zone_register() now ends up leaking its original tzp anddouble-freeing the tzp copy. Fix this by locating tzp on stack instead.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53998 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hwrng: virtio - Fix race on data_avail and actual dataThe virtio rng device kicks off a new entropy request whenever thedata available reaches zero. When a new request occurs at the endof a read operation, that is, when the result of that request isonly needed by the next reader, then there is a race between thewriting of the new data and the next reader.This is because there is no synchronisation whatsoever between thewriter and the reader.Fix this by writing data_avail with smp_store_release and readingit with smp_load_acquire when we first enter read. The subsequentreads are safe because they're either protected by the first loadacquire, or by the completion mechanism.Also remove the redundant zeroing of data_idx in random_recv_done(data_idx must already be zero at this point) and data_avail inrequest_entropy (ditto).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53999 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: TC, Fix internal port memory leakThe flow rule can be splited, and the extra post_act rules are addedto post_act table. It's possible to trigger memleak when the ruleforwards packets from internal port and over tunnel, in the case that,for example, CT 'new' state offload is allowed. As int_port object isassigned to the flow attribute of post_act rule, and its refcnt isincremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() isnot called, the refcnt is never decremented, then int_port is neverfreed.The kmemleak reports the following error:unreferenced object 0xffff888128204b80 (size 64): comm "handler20", pid 50121, jiffies 4296973009 (age 642.932s) hex dump (first 32 bytes): 01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00 ................ 98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff .wgA.....wgA.... backtrace: [<00000000e992680d>] kmalloc_trace+0x27/0x120 [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core] [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core] [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core] [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core] [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core] [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core] [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410 [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower] [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower] [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010 [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0 [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360 [<0000000082dd6c8b>] netlink_unicast+0x438/0x710 [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50 [<0000000016e92590>] sock_sendmsg+0xc5/0x190So fix this by moving int_port cleanup code to the flow attributefree helper, which is used by all the attribute free cases.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54000 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix deadlock issue when externel_lb and reset are executed togetherWhen externel_lb and reset are executed together, a deadlock mayoccur:[ 3147.217009] INFO: task kworker/u321:0:7 blocked for more than 120 seconds.[ 3147.230483] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.[ 3147.238999] task:kworker/u321:0 state:D stack: 0 pid: 7 ppid: 2 flags:0x00000008[ 3147.248045] Workqueue: hclge hclge_service_task [hclge][ 3147.253957] Call trace:[ 3147.257093] __switch_to+0x7c/0xbc[ 3147.261183] __schedule+0x338/0x6f0[ 3147.265357] schedule+0x50/0xe0[ 3147.269185] schedule_preempt_disabled+0x18/0x24[ 3147.274488] __mutex_lock.constprop.0+0x1d4/0x5dc[ 3147.279880] __mutex_lock_slowpath+0x1c/0x30[ 3147.284839] mutex_lock+0x50/0x60[ 3147.288841] rtnl_lock+0x20/0x2c[ 3147.292759] hclge_reset_prepare+0x68/0x90 [hclge][ 3147.298239] hclge_reset_subtask+0x88/0xe0 [hclge][ 3147.303718] hclge_reset_service_task+0x84/0x120 [hclge][ 3147.309718] hclge_service_task+0x2c/0x70 [hclge][ 3147.315109] process_one_work+0x1d0/0x490[ 3147.319805] worker_thread+0x158/0x3d0[ 3147.324240] kthread+0x108/0x13c[ 3147.328154] ret_from_fork+0x10/0x18In externel_lb process, the hns3 driver call napi_disable()first, then the reset happen, then the restore process of theexternel_lb will fail, and will not call napi_enable(). Whendoing externel_lb again, napi_disable() will be double call,cause a deadlock of rtnl_lock().This patch use the HNS3_NIC_STATE_DOWN state to protect thecalling of napi_disable() and napi_enable() in externel_lbprocess, just as the usage in ndo_stop() and ndo_start().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54001 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:staging: r8712: Fix memory leak in _r8712_init_xmit_priv()In the above mentioned routine, memory is allocated in several places.If the first succeeds and a later one fails, the routine will leak memory.This patch fixes commit 2865d42c78a9 ("staging: r8712u: Add the new driverto the mainline kernel"). A potential memory leak inr8712_xmit_resource_alloc() is also addressed.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54006 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data-race around unix_tot_inflight.unix_tot_inflight is changed under spin_lock(unix_gc_lock), butunix_release_sock() reads it locklessly.Let's use READ_ONCE() for unix_tot_inflight.Note that the writer side was marked by commit 9d6d7f1cb67c ("af_unix:annote lockless accesses to unix_tot_inflight & gc_in_progress")BUG: KCSAN: data-race in unix_inflight / unix_release_sockwrite (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1: unix_inflight+0x130/0x180 net/unix/scm.c:64 unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123 unix_scm_to_skb net/unix/af_unix.c:1832 [inline] unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x148/0x160 net/socket.c:747 ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493 ___sys_sendmsg+0xc6/0x140 net/socket.c:2547 __sys_sendmsg+0x94/0x140 net/socket.c:2576 __do_sys_sendmsg net/socket.c:2585 [inline] __se_sys_sendmsg net/socket.c:2583 [inline] __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583 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 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0: unix_release_sock+0x608/0x910 net/unix/af_unix.c:671 unix_release+0x59/0x80 net/unix/af_unix.c:1058 __sock_release+0x7d/0x170 net/socket.c:653 sock_close+0x19/0x30 net/socket.c:1385 __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/0xdcvalue changed: 0x00000000 -> 0x00000001Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54008 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:virtio_vdpa: build affinity masks conditionallyWe try to build affinity mask via create_affinity_masks()unconditionally which may lead several issues:- the affinity mask is not used for parent without affinity support (only VDUSE support the affinity now)- the logic of create_affinity_masks() might not work for devices other than block. For example it's not rare in the networking device where the number of queues could exceed the number of CPUs. Such case breaks the current affinity logic which is based on group_cpus_evenly() who assumes the number of CPUs are not less than the number of groups. This can trigger a warning[1]: if (ret >= 0) WARN_ON(nr_present + nr_others < numgrps);Fixing this by only build the affinity masks only when- Driver passes affinity descriptor, driver like virtio-blk can make sure to limit the number of queues when it exceeds the number of CPUs- Parent support affinity setting config opsThis help to avoid the warning. More optimizations could be done ontop.[1][ 682.146655] WARNING: CPU: 6 PID: 1550 at lib/group_cpus.c:400 group_cpus_evenly+0x1aa/0x1c0[ 682.146668] CPU: 6 PID: 1550 Comm: vdpa Not tainted 6.5.0-rc5jason+ #79[ 682.146671] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014[ 682.146673] RIP: 0010:group_cpus_evenly+0x1aa/0x1c0[ 682.146676] Code: 4c 89 e0 5b 5d 41 5c 41 5d 41 5e c3 cc cc cc cc e8 1b c4 74 ff 48 89 ef e8 13 ac 98 ff 4c 89 e7 45 31 e4 e8 08 ac 98 ff eb c2 <0f> 0b eb b6 e8 fd 05 c3 00 45 31 e4 eb e5 cc cc cc cc cc cc cc cc[ 682.146679] RSP: 0018:ffffc9000215f498 EFLAGS: 00010293[ 682.146682] RAX: 000000000001f1e0 RBX: 0000000000000041 RCX: 0000000000000000[ 682.146684] RDX: ffff888109922058 RSI: 0000000000000041 RDI: 0000000000000030[ 682.146686] RBP: ffff888109922058 R08: ffffc9000215f498 R09: ffffc9000215f4a0[ 682.146687] R10: 00000000000198d0 R11: 0000000000000030 R12: ffff888107e02800[ 682.146689] R13: 0000000000000030 R14: 0000000000000030 R15: 0000000000000041[ 682.146692] FS: 00007fef52315740(0000) GS:ffff888237380000(0000) knlGS:0000000000000000[ 682.146695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 682.146696] CR2: 00007fef52509000 CR3: 0000000110dbc004 CR4: 0000000000370ee0[ 682.146698] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 682.146700] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 682.146701] Call Trace:[ 682.146703] [ 682.146705] ? __warn+0x7b/0x130[ 682.146709] ? group_cpus_evenly+0x1aa/0x1c0[ 682.146712] ? report_bug+0x1c8/0x1e0[ 682.146717] ? handle_bug+0x3c/0x70[ 682.146721] ? exc_invalid_op+0x14/0x70[ 682.146723] ? asm_exc_invalid_op+0x16/0x20[ 682.146727] ? group_cpus_evenly+0x1aa/0x1c0[ 682.146729] ? group_cpus_evenly+0x15c/0x1c0[ 682.146731] create_affinity_masks+0xaf/0x1a0[ 682.146735] virtio_vdpa_find_vqs+0x83/0x1d0[ 682.146738] ? __pfx_default_calc_sets+0x10/0x10[ 682.146742] virtnet_find_vqs+0x1f0/0x370[ 682.146747] virtnet_probe+0x501/0xcd0[ 682.146749] ? vp_modern_get_status+0x12/0x20[ 682.146751] ? get_cap_addr.isra.0+0x10/0xc0[ 682.146754] virtio_dev_probe+0x1af/0x260[ 682.146759] really_probe+0x1a5/0x410

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54014 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Check valid rport returned by fc_bsg_to_rport()Klocwork reported warning of rport maybe NULL and will be dereferenced.rport returned by call to fc_bsg_to_rport() could be NULL and dereferenced.Check valid rport returned by fc_bsg_to_rport().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54019 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sched/psi: use kernfs polling functions for PSI trigger pollingDestroying psi trigger in cgroup_file_release causes UAF issues whena cgroup is removed from under a polling process. This is happeningbecause cgroup removal causes a call to cgroup_file_release while theactual file is still alive. Destroying the trigger at this point wouldalso destroy its waitqueue head and if there is still a polling processon that file accessing the waitqueue, it will step on the freed pointer:do_select vfs_poll do_rmdir cgroup_rmdir kernfs_drain_open_files cgroup_file_release cgroup_pressure_release psi_trigger_destroy wake_up_pollfree(&t->event_wait)// vfs_poll is unblocked synchronize_rcu kfree(t) poll_freewait -> UAF access to the trigger's waitqueue headPatch [1] fixed this issue for epoll() case using wake_up_pollfree(),however the same issue exists for synchronous poll() case.The root cause of this issue is that the lifecycles of the psi trigger'swaitqueue and of the file associated with the trigger are different. Fixthis by using kernfs_generic_poll function when polling on cgroup-specificpsi triggers. It internally uses kernfs_open_node->poll waitqueue headwith its lifecycle tied to the file's lifecycle. This also renders thefix in [1] obsolete, so revert it.[1] commit c2dbe32d5db5 ("sched/psi: Fix use-after-free in ep_remove_wait_queue()")

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54022 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Fix potential memory leaks at error path for UMP openThe allocation and initialization errors at alloc_midi_urbs() that iscalled at MIDI 2.0 / UMP device are supposed to be handled at thecaller side by invoking free_midi_urbs(). However, free_midi_urbs()loops only for ep->num_urbs entries, and since ep->num_entries wasn'tupdated yet at the allocation / init error in alloc_midi_urbs(), thisentry won't be released.The intention of free_midi_urbs() is to release the whole elements, sochange the loop size to NUM_URBS to scan over all elements for fixingthe missed releases.Also, the call of free_midi_urbs() is missing atsnd_usb_midi_v2_open(). Although it'll be released later atreopen/close or disconnection, it's better to release immediately atthe error path.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54025 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: rsi: Do not configure WoWlan in shutdown hook if not enabledIn case WoWlan was never configured during the operation of the system,the hw->wiphy->wowlan_config will be NULL. rsi_config_wowlan() checkswhether wowlan_config is non-NULL and if it is not, then WARNs about it.The warning is valid, as during normal operation the rsi_config_wowlan()should only ever be called with non-NULL wowlan_config. In shutdown thisrsi_config_wowlan() should only ever be called if WoWlan was configuredbefore by the user.Add checks for non-NULL wowlan_config into the shutdown hook. While at it,check whether the wiphy is also non-NULL before accessing wowlan_config .Drop the single-use wowlan_config variable, just inline it into functioncall.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54026 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:opp: Fix use-after-free in lazy_opp_tables after probe deferralWhen dev_pm_opp_of_find_icc_paths() in _allocate_opp_table() returns-EPROBE_DEFER, the opp_table is freed again, to wait until all theinterconnect paths are available.However, if the OPP table is using required-opps then it may alreadyhave been added to the global lazy_opp_tables list. The error pathdoes not remove the opp_table from the list again.This can cause crashes later when the provider of the required-oppsis added, since we will iterate over OPP tables that have already beenfreed. E.g.: Unable to handle kernel NULL pointer dereference when read CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.4.0-rc3 PC is at _of_add_opp_table_v2 (include/linux/of.h:949 drivers/opp/of.c:98 drivers/opp/of.c:344 drivers/opp/of.c:404 drivers/opp/of.c:1032) -> lazy_link_required_opp_table()Fix this by calling _of_clear_opp_table() to remove the opp_table fromthe list and clear other allocated resources. While at it, also add themissing mutex_destroy() calls in the error path.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54027 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iio: core: Prevent invalid memory access when there is no parentCommit 813665564b3d ("iio: core: Convert to use firmware node handleinstead of OF node") switched the kind of nodes to use for labelretrieval in device registration. Probably an unwanted change in thatcommit was that if the device has no parent then NULL pointer isaccessed. This is what happens in the stock IIO dummy driver when anew entry is created in configfs: # mkdir /sys/kernel/config/iio/devices/dummy/foo BUG: kernel NULL pointer dereference, address: ... ... Call Trace: __iio_device_register iio_dummy_probeSince there seems to be no reason to make a parent device of an IIOdummy device mandatory, let's prevent the invalid memory access in__iio_device_register when the parent device is NULL. With thischange, the IIO dummy driver works fine with configfs.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54031 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vdpa: Add queue index attr to vdpa_nl_policy for nlattr length checkThe vdpa_nl_policy structure is used to validate the nlattr when parsingthe incoming nlmsg. It will ensure the attribute being described producesa valid nlattr pointer in info->attrs before entering into each handlerin vdpa_nl_ops.That is to say, the missing part in vdpa_nl_policy may lead to illegalnlattr after parsing, which could lead to OOB read just like CVE-2023-3773.This patch adds the missing nla_policy for vdpa queue index attr to avoidsuch bugs.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54035 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix underflow in chain reference counterSet element addition error path decrements reference counter on chainstwice: once on element release and again via nft_data_release().Then, d6b478666ffa ("netfilter: nf_tables: fix underflow in objectreference counter") incorrectly fixed this by removing the statefulobject reference count decrement.Restore the stateful object decrement as in b91d90368837 ("netfilter:nf_tables: fix leaking object reference count") and letnft_data_release() decrement the chain reference counter, so this isdone only once.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54037 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ice: prevent NULL pointer deref during reloadCalling ethtool during reload can lead to call trace, because VSI isn'tconfigured for some time, but netdev is alive.To fix it add rtnl lock for VSI deconfig and config. Set ::num_q_vectorsto 0 after freeing and add a check for ::tx/rx_rings in ring relatedethtool ops.Add proper unroll of filters in ice_start_eth().Reproduction:$watch -n 0.1 -d 'ethtool -g enp24s0f0np0'$devlink dev reload pci/0000:18:00.0 action driver_reinitCall trace before fix:[66303.926205] BUG: kernel NULL pointer dereference, address: 0000000000000000[66303.926259] #PF: supervisor read access in kernel mode[66303.926286] #PF: error_code(0x0000) - not-present page[66303.926311] PGD 0 P4D 0[66303.926332] Oops: 0000 [#1] PREEMPT SMP PTI[66303.926358] CPU: 4 PID: 933821 Comm: ethtool Kdump: loaded Tainted: G OE 6.4.0-rc5+ #1[66303.926400] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0014.070920180847 07/09/2018[66303.926446] RIP: 0010:ice_get_ringparam+0x22/0x50 [ice][66303.926649] Code: 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 48 8b 87 c0 09 00 00 c7 46 04 e0 1f 00 00 c7 46 10 e0 1f 00 00 48 8b 50 20 <48> 8b 12 0f b7 52 3a 89 56 14 48 8b 40 28 48 8b 00 0f b7 40 58 48[66303.926722] RSP: 0018:ffffad40472f39c8 EFLAGS: 00010246[66303.926749] RAX: ffff98a8ada05828 RBX: ffff98a8c46dd060 RCX: ffffad40472f3b48[66303.926781] RDX: 0000000000000000 RSI: ffff98a8c46dd068 RDI: ffff98a8b23c4000[66303.926811] RBP: ffffad40472f3b48 R08: 00000000000337b0 R09: 0000000000000000[66303.926843] R10: 0000000000000001 R11: 0000000000000100 R12: ffff98a8b23c4000[66303.926874] R13: ffff98a8c46dd060 R14: 000000000000000f R15: ffffad40472f3a50[66303.926906] FS: 00007f6397966740(0000) GS:ffff98b390900000(0000) knlGS:0000000000000000[66303.926941] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[66303.926967] CR2: 0000000000000000 CR3: 000000011ac20002 CR4: 00000000007706e0[66303.926999] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[66303.927029] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[66303.927060] PKRU: 55555554[66303.927075] Call Trace:[66303.927094] [66303.927111] ? __die+0x23/0x70[66303.927140] ? page_fault_oops+0x171/0x4e0[66303.927176] ? exc_page_fault+0x7f/0x180[66303.927209] ? asm_exc_page_fault+0x26/0x30[66303.927244] ? ice_get_ringparam+0x22/0x50 [ice][66303.927433] rings_prepare_data+0x62/0x80[66303.927469] ethnl_default_doit+0xe2/0x350[66303.927501] genl_family_rcv_msg_doit.isra.0+0xe3/0x140[66303.927538] genl_rcv_msg+0x1b1/0x2c0[66303.927561] ? __pfx_ethnl_default_doit+0x10/0x10[66303.927590] ? __pfx_genl_rcv_msg+0x10/0x10[66303.927615] netlink_rcv_skb+0x58/0x110[66303.927644] genl_rcv+0x28/0x40[66303.927665] netlink_unicast+0x19e/0x290[66303.927691] netlink_sendmsg+0x254/0x4d0[66303.927717] sock_sendmsg+0x93/0xa0[66303.927743] __sys_sendto+0x126/0x170[66303.927780] __x64_sys_sendto+0x24/0x30[66303.928593] do_syscall_64+0x5d/0x90[66303.929370] ? __count_memcg_events+0x60/0xa0[66303.930146] ? count_memcg_events.constprop.0+0x1a/0x30[66303.930920] ? handle_mm_fault+0x9e/0x350[66303.931688] ? do_user_addr_fault+0x258/0x740[66303.932452] ? exc_page_fault+0x7f/0x180[66303.933193] entry_SYSCALL_64_after_hwframe+0x72/0xdc

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54038 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_conn: return ERR_PTR instead of NULL when there is no linkhci_connect_sco currently returns NULL when there is no link (i.e. whenhci_conn_link() returns NULL).sco_connect() expects an ERR_PTR in case of any error (see line 266 insco.c). Thus, hcon set as NULL passes through to sco_conn_add(), whichtries to get hcon->hdev, resulting in dereferencing a NULL pointer asreported by syzkaller.The same issue exists for iso_connect_cis() calling hci_connect_cis().Thus, make hci_connect_sco() and hci_connect_cis() return ERR_PTRinstead of NULL.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54045 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:audit: fix possible soft lockup in __audit_inode_child()Tracefs or debugfs maybe cause hundreds to thousands of PATH records,too many PATH records maybe cause soft lockup.For example: 1. CONFIG_KASAN=y && CONFIG_PREEMPTION=n 2. auditctl -a exit,always -S open -k key 3. sysctl -w kernel.watchdog_thresh=5 4. mkdir /sys/kernel/debug/tracing/instances/testThere may be a soft lockup as follows: watchdog: BUG: soft lockup - CPU#45 stuck for 7s! [mkdir:15498] Kernel panic - not syncing: softlockup: hung tasks Call trace: dump_backtrace+0x0/0x30c show_stack+0x20/0x30 dump_stack+0x11c/0x174 panic+0x27c/0x494 watchdog_timer_fn+0x2bc/0x390 __run_hrtimer+0x148/0x4fc __hrtimer_run_queues+0x154/0x210 hrtimer_interrupt+0x2c4/0x760 arch_timer_handler_phys+0x48/0x60 handle_percpu_devid_irq+0xe0/0x340 __handle_domain_irq+0xbc/0x130 gic_handle_irq+0x78/0x460 el1_irq+0xb8/0x140 __audit_inode_child+0x240/0x7bc tracefs_create_file+0x1b8/0x2a0 trace_create_file+0x18/0x50 event_create_dir+0x204/0x30c __trace_add_new_event+0xac/0x100 event_trace_add_tracer+0xa0/0x130 trace_array_create_dir+0x60/0x140 trace_array_create+0x1e0/0x370 instance_mkdir+0x90/0xd0 tracefs_syscall_mkdir+0x68/0xa0 vfs_mkdir+0x21c/0x34c do_mkdirat+0x1b4/0x1d4 __arm64_sys_mkdirat+0x4c/0x60 el0_svc_common.constprop.0+0xa8/0x240 do_el0_svc+0x8c/0xc0 el0_svc+0x20/0x30 el0_sync_handler+0xb0/0xb4 el0_sync+0x160/0x180Therefore, we add cond_resched() to __audit_inode_child() to fix it.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54048 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:RDMA/bnxt_re: Prevent handling any completions after qp destroyHW may generate completions that indicates QP is destroyed.Driver should not be scheduling any more completion handlersfor this QP, after the QP is destroyed. Since CQs are activeduring the QP destroy, driver may still schedule completionhandlers. This can cause a race where the destroy_cq and poll_cqrunning simultaneously.Snippet of kernel panic while doing bnxt_re driver load unload in loop.This indicates a poll after the CQ is freed. [77786.481636] Call Trace:[77786.481640] [77786.481644] bnxt_re_poll_cq+0x14a/0x620 [bnxt_re][77786.481658] ? kvm_clock_read+0x14/0x30[77786.481693] __ib_process_cq+0x57/0x190 [ib_core][77786.481728] ib_cq_poll_work+0x26/0x80 [ib_core][77786.481761] process_one_work+0x1e5/0x3f0[77786.481768] worker_thread+0x50/0x3a0[77786.481785] ? __pfx_worker_thread+0x10/0x10[77786.481790] kthread+0xe2/0x110[77786.481794] ? __pfx_kthread+0x10/0x10[77786.481797] ret_from_fork+0x2c/0x50To avoid this, complete all completion handlers before returning thedestroy QP. If free_cq is called soon after destroy_qp, IB stackwill cancel the CQ work before invoking the destroy_cq verb andthis will prevent any race mentioned.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54049 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:rpmsg: glink: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54051 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net: do not allow gso_size to be set to GSO_BY_FRAGSOne missing check in virtio_net_hdr_to_skb() allowedsyzbot to crash kernels again [1]Do not allow gso_size to be set to GSO_BY_FRAGS (0xffff),because this magic value is used by the kernel.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 0 PID: 5039 Comm: syz-executor401 Not tainted 6.5.0-rc5-next-20230809-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023RIP: 0010:skb_segment+0x1a52/0x3ef0 net/core/skbuff.c:4500Code: 00 00 00 e9 ab eb ff ff e8 6b 96 5d f9 48 8b 84 24 00 01 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 ea 21 00 00 48 8b 84 24 00 01RSP: 0018:ffffc90003d3f1c8 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 000000000001fffe RCX: 0000000000000000RDX: 000000000000000e RSI: ffffffff882a3115 RDI: 0000000000000070RBP: ffffc90003d3f378 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 5ee4a93e456187d6 R12: 000000000001ffc6R13: dffffc0000000000 R14: 0000000000000008 R15: 000000000000ffffFS: 00005555563f2380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020020000 CR3: 000000001626d000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:udp6_ufo_fragment+0x9d2/0xd50 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x5c4/0x17b0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x292/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+0x3a5/0xf10 net/core/dev.c:3625__dev_queue_xmit+0x8f0/0x3d60 net/core/dev.c:4329dev_queue_xmit include/linux/netdevice.h:3082 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c7/0x5570 net/packet/af_packet.c:3119sock_sendmsg_nosec net/socket.c:727 [inline]sock_sendmsg+0xd9/0x180 net/socket.c:750____sys_sendmsg+0x6ac/0x940 net/socket.c:2496___sys_sendmsg+0x135/0x1d0 net/socket.c:2550__sys_sendmsg+0x117/0x1e0 net/socket.c:2579do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x38/0xb0 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdRIP: 0033:0x7ff27cdb34d9

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54060 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Set end correctly when doing batch carryEven though the test suite covers this it somehow became obscured thatthis wasn't working.The test iommufd_ioas.mock_domain.access_domain_destory would blow uprarely.end should be set to 1 because this just pushed an item, the carry, to thepfns list.Sometimes the test would blow up with: 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: 0000 [#1] SMP CPU: 5 PID: 584 Comm: iommufd Not tainted 6.5.0-rc1-dirty #1236 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:batch_unpin+0xa2/0x100 [iommufd] Code: 17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 c1 e6 04 48 01 f2 <48> 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc RSP: 0018:ffffc90001677a58 EFLAGS: 00010246 RAX: 00007f7e2646f000 RBX: 0000000000000000 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 00000000fefc4c8d RDI: 0000000000fefc4c RBP: ffffc90001677a80 R08: 0000000000000048 R09: 0000000000000200 R10: 0000000000030b98 R11: ffffffff81f3bb40 R12: 0000000000000001 R13: ffff888101f75800 R14: ffffc90001677ad0 R15: 00000000000001fe FS: 00007f9323679740(0000) GS:ffff8881ba540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000105ede003 CR4: 00000000003706a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x5c/0x70 ? __die+0x1f/0x60 ? page_fault_oops+0x15d/0x440 ? lock_release+0xbc/0x240 ? exc_page_fault+0x4a4/0x970 ? asm_exc_page_fault+0x27/0x30 ? batch_unpin+0xa2/0x100 [iommufd] ? batch_unpin+0xba/0x100 [iommufd] __iopt_area_unfill_domain+0x198/0x430 [iommufd] ? __mutex_lock+0x8c/0xb80 ? __mutex_lock+0x6aa/0xb80 ? xa_erase+0x28/0x30 ? iopt_table_remove_domain+0x162/0x320 [iommufd] ? lock_release+0xbc/0x240 iopt_area_unfill_domain+0xd/0x10 [iommufd] iopt_table_remove_domain+0x195/0x320 [iommufd] iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd] iommufd_object_destroy_user+0x8e/0xf0 [iommufd] iommufd_device_detach+0xc5/0x140 [iommufd] iommufd_selftest_destroy+0x1f/0x70 [iommufd] iommufd_object_destroy_user+0x8e/0xf0 [iommufd] iommufd_destroy+0x3a/0x50 [iommufd] iommufd_fops_ioctl+0xfb/0x170 [iommufd] __x64_sys_ioctl+0x40d/0x9a0 do_syscall_64+0x3c/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54064 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ipmi:ssif: Fix a memory leak when scanning for an adapterThe adapter scan ssif_info_find() sets info->adapter_name if the adapterinfo came from SMBIOS, as it's not set in that case. However, thisfunction can be called more than once, and it will leak the adapter nameif it had already been set. So check for NULL before setting it.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54069 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: fix BUG in ext4_mb_new_inode_pa() due to overflowWhen we calculate the end position of ext4_free_extent, this position maybe exactly where ext4_lblk_t (i.e. uint) overflows. For example, ifac_g_ex.fe_logical is 4294965248 and ac_orig_goal_len is 2048, then thecomputed end is 0x100000000, which is 0. If ac->ac_o_ex.fe_logical is notthe first case of adjusting the best extent, that is, new_bex_end > 0, thefollowing BUG_ON will be triggered:=========================================================kernel BUG at fs/ext4/mballoc.c:5116!invalid opcode: 0000 [#1] PREEMPT SMP PTICPU: 3 PID: 673 Comm: xfs_io Tainted: G E 6.5.0-rc1+ #279RIP: 0010:ext4_mb_new_inode_pa+0xc5/0x430Call Trace: ext4_mb_use_best_found+0x203/0x2f0 ext4_mb_try_best_found+0x163/0x240 ext4_mb_regular_allocator+0x158/0x1550 ext4_mb_new_blocks+0x86a/0xe10 ext4_ext_map_blocks+0xb0c/0x13a0 ext4_map_blocks+0x2cd/0x8f0 ext4_iomap_begin+0x27b/0x400 iomap_iter+0x222/0x3d0 __iomap_dio_rw+0x243/0xcb0 iomap_dio_rw+0x16/0x80=========================================================A simple reproducer demonstrating the problem: mkfs.ext4 -F /dev/sda -b 4096 100M mount /dev/sda /tmp/test fallocate -l1M /tmp/test/tmp fallocate -l10M /tmp/test/file fallocate -i -o 1M -l16777203M /tmp/test/file fsstress -d /tmp/test -l 0 -n 100000 -p 8 & sleep 10 && killall -9 fsstress rm -f /tmp/test/tmp xfs_io -c "open -ad /tmp/test/file" -c "pwrite -S 0xff 0 8192"We simply refactor the logic for adjusting the best extent by addinga temporary ext4_free_extent ex and use extent_logical_end() to avoidoverflow, which also simplifies the code.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54088 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: hold queue_lock when removing blkg->q_nodeWhen blkg is removed from q->blkg_list from blkg_free_workfn(), queue_lockhas to be held, otherwise, all kinds of bugs(list corruption, hard lockup,..) can be triggered from blkg_destroy_all().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54092 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: s390: pv: fix index value of replaced ASCEThe index field of the struct page corresponding to a guest ASCE shouldbe 0. When replacing the ASCE in s390_replace_asce(), the index of thenew ASCE should also be set to 0.Having the wrong index might lead to the wrong addresses being passedaround when notifying pte invalidations, and eventually to validityintercepts (VM crash) if the prefix gets unmapped and the notifier getscalled with the wrong address.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54095 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/iommu: Fix notifiers being shared by PCI and VIO busesfail_iommu_setup() registers the fail_iommu_bus_notifier struct to bothPCI and VIO buses. struct notifier_block is a linked list node, so thiscauses any notifiers later registered to either bus type to also beregistered to the other since they share the same node.This causes issues in (at least) the vgaarb code, which registers anotifier for PCI buses. pci_notify() ends up being called on a viodevice, converted with to_pci_dev() even though it's not a PCI device,and finally makes a bad access in vga_arbiter_add_pci_device() asdiscovered with KASAN: BUG: KASAN: slab-out-of-bounds in vga_arbiter_add_pci_device+0x60/0xe00 Read of size 4 at addr c000000264c26fdc by task swapper/0/1 Call Trace: dump_stack_lvl+0x1bc/0x2b8 (unreliable) print_report+0x3f4/0xc60 kasan_report+0x244/0x698 __asan_load4+0xe8/0x250 vga_arbiter_add_pci_device+0x60/0xe00 pci_notify+0x88/0x444 notifier_call_chain+0x104/0x320 blocking_notifier_call_chain+0xa0/0x140 device_add+0xac8/0x1d30 device_register+0x58/0x80 vio_register_device_node+0x9ac/0xce0 vio_bus_scan_register_devices+0xc4/0x13c __machine_initcall_pseries_vio_device_init+0x94/0xf0 do_one_initcall+0x12c/0xaa8 kernel_init_freeable+0xa48/0xba8 kernel_init+0x64/0x400 ret_from_kernel_thread+0x5c/0x64Fix this by creating separate notifier_block structs for each bus type.[mpe: Add #ifdef to fix CONFIG_IBMVIO=n build]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54106 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: fix potential memory leak in mlx5e_init_rep_rxThe memory pointed to by the priv->rx_res pointer is not freed in the errorpath of mlx5e_init_rep_rx, which can lead to a memory leak. Fix by freeingthe memory in the error path, thereby making the error path identical tomlx5e_cleanup_rep_rx().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54117 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:s390/dcssblk: fix kernel crash with list_add corruptionCommit fb08a1908cb1 ("dax: simplify the dax_device <-> gendiskassociation") introduced new logic for gendisk association, requiringdrivers to explicitly call dax_add_host() and dax_remove_host().For dcssblk driver, some dax_remove_host() calls were missing, e.g. indevice remove path. The commit also broke error handling for out_dax casein device add path, resulting in an extra put_device() w/o the previousget_device() in that case.This lead to stale xarray entries after device add / remove cycles. In thecase when a previously used struct gendisk pointer (xarray index) would beused again, because blk_alloc_disk() happened to return such a pointer, thexa_insert() in dax_add_host() would fail and go to out_dax, doing the extraput_device() in the error path. In combination with an already flawed errorhandling in dcssblk (device_register() cleanup), which needs to beaddressed in a separate patch, this resulted in a missing device_del() /klist_del(), and eventually in the kernel crash with list_add corruption ona subsequent device_add() / klist_add().Fix this by adding the missing dax_remove_host() calls, and also move theput_device() in the error path to restore the previous logic.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54141 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: Add missing hw_ops->get_ring_selector() for IPQ5018During sending data after clients connected, hw_ops->get_ring_selector()will be called. But for IPQ5018, this member isn't set, and thefollowing NULL pointer exception will be occurred: [ 38.840478] 8<--- cut here --- [ 38.840517] Unable to handle kernel NULL pointer dereference at virtual address 00000000 ... [ 38.923161] PC is at 0x0 [ 38.927930] LR is at ath11k_dp_tx+0x70/0x730 [ath11k] ... [ 39.063264] Process hostapd (pid: 1034, stack limit = 0x801ceb3d) [ 39.068994] Stack: (0x856a9a68 to 0x856aa000) ... [ 39.438467] [<7f323804>] (ath11k_dp_tx [ath11k]) from [<7f314e6c>] (ath11k_mac_op_tx+0x80/0x190 [ath11k]) [ 39.446607] [<7f314e6c>] (ath11k_mac_op_tx [ath11k]) from [<7f17dbe0>] (ieee80211_handle_wake_tx_queue+0x7c/0xc0 [mac80211]) [ 39.456162] [<7f17dbe0>] (ieee80211_handle_wake_tx_queue [mac80211]) from [<7f174450>] (ieee80211_probereq_get+0x584/0x704 [mac80211]) [ 39.467443] [<7f174450>] (ieee80211_probereq_get [mac80211]) from [<7f178c40>] (ieee80211_tx_prepare_skb+0x1f8/0x248 [mac80211]) [ 39.479334] [<7f178c40>] (ieee80211_tx_prepare_skb [mac80211]) from [<7f179e28>] (__ieee80211_subif_start_xmit+0x32c/0x3d4 [mac80211]) [ 39.491053] [<7f179e28>] (__ieee80211_subif_start_xmit [mac80211]) from [<7f17af08>] (ieee80211_tx_control_port+0x19c/0x288 [mac80211]) [ 39.502946] [<7f17af08>] (ieee80211_tx_control_port [mac80211]) from [<7f0fc704>] (nl80211_tx_control_port+0x174/0x1d4 [cfg80211]) [ 39.515017] [<7f0fc704>] (nl80211_tx_control_port [cfg80211]) from [<808ceac4>] (genl_rcv_msg+0x154/0x340) [ 39.526814] [<808ceac4>] (genl_rcv_msg) from [<808cdb74>] (netlink_rcv_skb+0xb8/0x11c) [ 39.536446] [<808cdb74>] (netlink_rcv_skb) from [<808ce1d0>] (genl_rcv+0x28/0x34) [ 39.544344] [<808ce1d0>] (genl_rcv) from [<808cd234>] (netlink_unicast+0x174/0x274) [ 39.551895] [<808cd234>] (netlink_unicast) from [<808cd510>] (netlink_sendmsg+0x1dc/0x440) [ 39.559362] [<808cd510>] (netlink_sendmsg) from [<808596e0>] (____sys_sendmsg+0x1a8/0x1fc) [ 39.567697] [<808596e0>] (____sys_sendmsg) from [<8085b1a8>] (___sys_sendmsg+0xa4/0xdc) [ 39.575941] [<8085b1a8>] (___sys_sendmsg) from [<8085b310>] (sys_sendmsg+0x44/0x74) [ 39.583841] [<8085b310>] (sys_sendmsg) from [<80300060>] (ret_fast_syscall+0x0/0x40) ... [ 39.620734] Code: bad PC value [ 39.625869] ---[ end trace 8aef983ad3cbc032 ]---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54153 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: turn quotas off if mount failed after enabling quotasYi found during a review of the patch "ext4: don't BUG on inconsistentjournal feature" that when ext4_mark_recovery_complete() returns an errorvalue, the error handling path does not turn off the enabled quotas,which triggers the following kmemleak:================================================================unreferenced object 0xffff8cf68678e7c0 (size 64):comm "mount", pid 746, jiffies 4294871231 (age 11.540s)hex dump (first 32 bytes):00 90 ef 82 f6 8c ff ff 00 00 00 00 41 01 00 00 ............A...c7 00 00 00 bd 00 00 00 0a 00 00 00 48 00 00 00 ............H...backtrace:[<00000000c561ef24>] __kmem_cache_alloc_node+0x4d4/0x880[<00000000d4e621d7>] kmalloc_trace+0x39/0x140[<00000000837eee74>] v2_read_file_info+0x18a/0x3a0[<0000000088f6c877>] dquot_load_quota_sb+0x2ed/0x770[<00000000340a4782>] dquot_load_quota_inode+0xc6/0x1c0[<0000000089a18bd5>] ext4_enable_quotas+0x17e/0x3a0 [ext4][<000000003a0268fa>] __ext4_fill_super+0x3448/0x3910 [ext4][<00000000b0f2a8a8>] ext4_fill_super+0x13d/0x340 [ext4][<000000004a9489c4>] get_tree_bdev+0x1dc/0x370[<000000006e723bf1>] ext4_get_tree+0x1d/0x30 [ext4][<00000000c7cb663d>] vfs_get_tree+0x31/0x160[<00000000320e1bed>] do_new_mount+0x1d5/0x480[<00000000c074654c>] path_mount+0x22e/0xbe0[<0000000003e97a8e>] do_mount+0x95/0xc0[<000000002f3d3736>] __x64_sys_mount+0xc4/0x160[<0000000027d2140c>] do_syscall_64+0x3f/0x90================================================================To solve this problem, we add a "failed_mount10" tag, and callext4_quota_off_umount() in this tag to release the enabled qoutas.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54156 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:sfc: fix crash when reading stats while NIC is resettingefx_net_stats() (.ndo_get_stats64) can be called during an ethtool selftest, during which time nic_data->mc_stats is NULL as the NIC has been fini'd. In this case do not attempt to fetch the latest stats from the hardware, else we will crash on a NULL dereference: BUG: kernel NULL pointer dereference, address: 0000000000000038 RIP efx_nic_update_stats abridged calltrace: efx_ef10_update_stats_pf efx_net_stats dev_get_stats dev_seq_printf_statsSkipping the read is safe, we will simply give out stale stats.To ensure that the free in efx_ef10_fini_nic() does not race against efx_ef10_update_stats_pf(), which could cause a TOCTTOU bug, take the efx->stats_lock in fini_nic (it is already held across update_stats).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54164 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: ISO: fix iso_conn related locking and validity issuessk->sk_state indicates whether iso_pi(sk)->conn is valid. Operationsthat check/update sk_state and access conn should hold lock_sock,otherwise they can race.The order of taking locks is hci_dev_lock > lock_sock > iso_conn_lock,which is how it is in connect/disconnect_cfm -> iso_conn_del ->iso_chan_del.Fix locking in iso_connect_cis/bis and sendmsg/recvmsg to take lock_sockaround updating sk_state and conn.iso_conn_del must not occur during iso_connect_cis/bis, as it frees theiso_conn. Hold hdev->lock longer to prevent that.This should not reintroduce the issue fixed in commit 241f51931c35("Bluetooth: ISO: Avoid circular locking dependency"), since the weacquire locks in order. We retain the fix in iso_sock_connect to releaselock_sock before iso_connect_* acquires hdev->lock.Similarly for commit 6a5ad251b7cd ("Bluetooth: ISO: Fix possiblecircular locking dependency"). We retain the fix in iso_conn_ready tonot acquire iso_conn_lock before lock_sock.iso_conn_add shall return iso_conn with valid hcon. Make it so also whenreusing an old CIS connection waiting for disconnect timeout (see__iso_sock_close where conn->hcon is set to NULL).Trace with iso_conn_del after iso_chan_add in iso_connect_cis:===============================================================iso_sock_create:771: sock 00000000be9b69b7iso_sock_init:693: sk 000000004dff667eiso_sock_bind:827: sk 000000004dff667e 70:1a:b8:98:ff:a2 type 1iso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_setsockopt:1289: sk 000000004dff667eiso_sock_connect:875: sk 000000004dff667eiso_connect_cis:353: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:dahci_get_route:1199: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:dahci_conn_add:1005: hci0 dst 28:3d:c2:4a:7e:daiso_conn_add:140: hcon 000000007b65d182 conn 00000000daf8625e__iso_chan_add:214: conn 00000000daf8625eiso_connect_cfm:1700: hcon 000000007b65d182 bdaddr 28:3d:c2:4a:7e:da status 12iso_conn_del:187: hcon 000000007b65d182 conn 00000000daf8625e, err 16iso_sock_clear_timer:117: sock 000000004dff667e state 3 iso_chan_del:153: sk 000000004dff667e, conn 00000000daf8625e, err 16hci_conn_del:1151: hci0 hcon 000000007b65d182 handle 65535hci_conn_unlink:1102: hci0: hcon 000000007b65d182hci_chan_list_flush:2780: hcon 000000007b65d182iso_sock_getsockopt:1376: sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getsockopt:1376: sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_getname:1070: sock 00000000be9b69b7, sk 000000004dff667eiso_sock_shutdown:1434: sock 00000000be9b69b7, sk 000000004dff667e, how 1__iso_sock_close:632: sk 000000004dff667e state 5 socket 00000000be9b69b7 BUG: kernel NULL pointer dereference, address: 0000000000000000PGD 8000000006467067 P4D 8000000006467067 PUD 3f5f067 PMD 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_close (net/bluetooth/iso.c:664) bluetooth===============================================================Trace with iso_conn_del before iso_chan_add in iso_connect_cis:===============================================================iso_connect_cis:356: 70:1a:b8:98:ff:a2 -> 28:3d:c2:4a:7e:da...iso_conn_add:140: hcon 0000000093bc551f conn 00000000768ae504hci_dev_put:1487: hci0 orig refcnt 21hci_event_packet:7607: hci0: e---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/hyperv: Disable IBT when hypercall page lacks ENDBR instructionOn hardware that supports Indirect Branch Tracking (IBT), Hyper-V VMswith ConfigVersion 9.3 or later support IBT in the guest. However,current versions of Hyper-V have a bug in that there's not an ENDBR64instruction at the beginning of the hypercall page. Since hypercalls aremade with an indirect call to the hypercall page, all hypercall attemptsfail with an exception and Linux panics.A Hyper-V fix is in progress to add ENDBR64. But guard against the Linuxpanic by clearing X86_FEATURE_IBT if the hypercall page doesn't startwith ENDBR. The VM will boot and run without IBT.If future Linux 32-bit kernels were to support IBT, additional hypercallpage hackery would be needed to make IBT work for such kernels in aHyper-V VM.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54173 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Disable preemption in bpf_event_outputWe received report [1] of kernel crash, which is caused byusing nesting protection without disabled preemption.The bpf_event_output can be called by programs executed bybpf_prog_run_array_cg function that disabled migration butkeeps preemption enabled.This can cause task to be preempted by another one inside thenesting protection and lead eventually to two tasks using sameperf_sample_data buffer and cause crashes like: BUG: kernel NULL pointer dereference, address: 0000000000000001 #PF: supervisor instruction fetch in kernel mode #PF: error_code(0x0010) - not-present page ... ? perf_output_sample+0x12a/0x9a0 ? finish_task_switch.isra.0+0x81/0x280 ? perf_event_output+0x66/0xa0 ? bpf_event_output+0x13a/0x190 ? bpf_event_output_data+0x22/0x40 ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb ? xa_load+0x87/0xe0 ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0 ? release_sock+0x3e/0x90 ? sk_setsockopt+0x1a1/0x12f0 ? udp_pre_connect+0x36/0x50 ? inet_dgram_connect+0x93/0xa0 ? __sys_connect+0xb4/0xe0 ? udp_setsockopt+0x27/0x40 ? __pfx_udp_push_pending_frames+0x10/0x10 ? __sys_setsockopt+0xdf/0x1a0 ? __x64_sys_connect+0xf/0x20 ? do_syscall_64+0x3a/0x90 ? entry_SYSCALL_64_after_hwframe+0x72/0xdcFixing this by disabling preemption in bpf_event_output.[1] https://github.com/cilium/cilium/issues/26756

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54189 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pstore/ram: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54204 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mmc: sunplus: fix return value check of mmc_add_host()mmc_add_host() may return error, if we ignore its return value,1. the memory allocated in mmc_alloc_host() will be leaked2. null-ptr-deref will happen when calling mmc_remove_host()in remove function spmmc_drv_remove() because deleting notadded device.Fix this by checking the return value of mmc_add_host(). Moreover,I fixed the error handling path of spmmc_drv_probe() to clean up.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54211 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:tracing: Fix warning in trace_buffered_event_disable()Warning happened in trace_buffered_event_disable() at WARN_ON_ONCE(!trace_buffered_event_ref) Call Trace: ? __warn+0xa5/0x1b0 ? trace_buffered_event_disable+0x189/0x1b0 __ftrace_event_enable_disable+0x19e/0x3e0 free_probe_data+0x3b/0xa0 unregister_ftrace_function_probe_func+0x6b8/0x800 event_enable_func+0x2f0/0x3d0 ftrace_process_regex.isra.0+0x12d/0x1b0 ftrace_filter_write+0xe6/0x140 vfs_write+0x1c9/0x6f0 [...]The cause of the warning is in __ftrace_event_enable_disable(),trace_buffered_event_enable() was called once whiletrace_buffered_event_disable() was called twice.Reproduction script show as below, for analysis, see the comments: ``` #!/bin/bash cd /sys/kernel/tracing/ # 1. Register a 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was set; # 2) trace_buffered_event_enable() was called first time; echo 'cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter # 2. Enable the event registered, then: # 1) SOFT_DISABLED_BIT was cleared; # 2) trace_buffered_event_disable() was called first time; echo 1 > events/initcall/initcall_finish/enable # 3. Try to call into cmdline_proc_show(), then SOFT_DISABLED_BIT was # set again!!! cat /proc/cmdline # 4. Unregister the 'disable_event' command, then: # 1) SOFT_DISABLED_BIT was cleared again; # 2) trace_buffered_event_disable() was called second time!!! echo '!cmdline_proc_show:disable_event:initcall:initcall_finish' > \ set_ftrace_filter ```To fix it, IIUC, we can change to call trace_buffered_event_enable() atfist time soft-mode enabled, and call trace_buffered_event_disable() atlast time soft-mode disabled.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54223 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: xsk: Fix invalid buffer access for legacy rqThe below crash can be encountered when using xdpsock in rx mode forlegacy rq: the buffer gets released in the XDP_REDIRECT path, and thenonce again in the driver. This fix sets the flag to avoid releasing onthe driver side.XSK handling of buffers for legacy rq was relying on the caller to setthe skip release flag. But the referenced fix started using fragmentcounts for pages instead of the skip flag.Crash log: general protection fault, probably for non-canonical address 0xffff8881217e3a: 0000 [#1] SMP CPU: 0 PID: 14 Comm: ksoftirqd/0 Not tainted 6.5.0-rc1+ #31 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:bpf_prog_03b13f331978c78c+0xf/0x28 Code: ... RSP: 0018:ffff88810082fc98 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888138404901 RCX: c0ffffc900027cbc RDX: ffffffffa000b514 RSI: 00ffff8881217e32 RDI: ffff888138404901 RBP: ffff88810082fc98 R08: 0000000000091100 R09: 0000000000000006 R10: 0000000000000800 R11: 0000000000000800 R12: ffffc9000027a000 R13: ffff8881217e2dc0 R14: ffff8881217e2910 R15: ffff8881217e2f00 FS: 0000000000000000(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000564cb2e2cde0 CR3: 000000010e603004 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x32/0x80 ? exc_general_protection+0x192/0x390 ? asm_exc_general_protection+0x22/0x30 ? 0xffffffffa000b514 ? bpf_prog_03b13f331978c78c+0xf/0x28 mlx5e_xdp_handle+0x48/0x670 [mlx5_core] ? dev_gro_receive+0x3b5/0x6e0 mlx5e_xsk_skb_from_cqe_linear+0x6e/0x90 [mlx5_core] mlx5e_handle_rx_cqe+0x55/0x100 [mlx5_core] mlx5e_poll_rx_cq+0x87/0x6e0 [mlx5_core] mlx5e_napi_poll+0x45e/0x6b0 [mlx5_core] __napi_poll+0x25/0x1a0 net_rx_action+0x28a/0x300 __do_softirq+0xcd/0x279 ? sort_range+0x20/0x20 run_ksoftirqd+0x1a/0x20 smpboot_thread_fn+0xa2/0x130 kthread+0xc9/0xf0 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x1f/0x30 Modules linked in: mlx5_ib mlx5_core rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter overlay zram zsmalloc fuse [last unloaded: mlx5_core] ---[ end trace 0000000000000000 ]---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54241 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:MIPS: KVM: Fix NULL pointer dereferenceAfter commit 45c7e8af4a5e3f0bea4ac209 ("MIPS: Remove KVM_TE support") weget a NULL pointer dereference when creating a KVM guest:[ 146.243409] Starting KVM with MIPS VZ extensions[ 149.849151] CPU 3 Unable to handle kernel paging request at virtual address 0000000000000300, epc == ffffffffc06356ec, ra == ffffffffc063568c[ 149.849177] Oops[#1]:[ 149.849182] CPU: 3 PID: 2265 Comm: qemu-system-mip Not tainted 6.4.0-rc3+ #1671[ 149.849188] Hardware name: THTF CX TL630 Series/THTF-LS3A4000-7A1000-ML4A, BIOS KL4.1F.TF.D.166.201225.R 12/25/2020[ 149.849192] $ 0 : 0000000000000000 000000007400cce0 0000000000400004 ffffffff8119c740[ 149.849209] $ 4 : 000000007400cce1 000000007400cce1 0000000000000000 0000000000000000[ 149.849221] $ 8 : 000000240058bb36 ffffffff81421ac0 0000000000000000 0000000000400dc0[ 149.849233] $12 : 9800000102a07cc8 ffffffff80e40e38 0000000000000001 0000000000400dc0[ 149.849245] $16 : 0000000000000000 9800000106cd0000 9800000106cd0000 9800000100cce000[ 149.849257] $20 : ffffffffc0632b28 ffffffffc05b31b0 9800000100ccca00 0000000000400000[ 149.849269] $24 : 9800000106cd09ce ffffffff802f69d0[ 149.849281] $28 : 9800000102a04000 9800000102a07cd0 98000001106a8000 ffffffffc063568c[ 149.849293] Hi : 00000335b2111e66[ 149.849295] Lo : 6668d90061ae0ae9[ 149.849298] epc : ffffffffc06356ec kvm_vz_vcpu_setup+0xc4/0x328 [kvm][ 149.849324] ra : ffffffffc063568c kvm_vz_vcpu_setup+0x64/0x328 [kvm][ 149.849336] Status: 7400cce3 KX SX UX KERNEL EXL IE[ 149.849351] Cause : 1000000c (ExcCode 03)[ 149.849354] BadVA : 0000000000000300[ 149.849357] PrId : 0014c004 (ICT Loongson-3)[ 149.849360] Modules linked in: kvm nfnetlink_queue nfnetlink_log nfnetlink fuse sha256_generic libsha256 cfg80211 rfkill binfmt_misc vfat fat snd_hda_codec_hdmi input_leds led_class snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_pcm snd_timer snd serio_raw xhci_pci radeon drm_suballoc_helper drm_display_helper xhci_hcd ip_tables x_tables[ 149.849432] Process qemu-system-mip (pid: 2265, threadinfo=00000000ae2982d2, task=0000000038e09ad4, tls=000000ffeba16030)[ 149.849439] Stack : 9800000000000003 9800000100ccca00 9800000100ccc000 ffffffffc062cef4[ 149.849453] 9800000102a07d18 c89b63a7ab338e00 0000000000000000 ffffffff811a0000[ 149.849465] 0000000000000000 9800000106cd0000 ffffffff80e59938 98000001106a8920[ 149.849476] ffffffff80e57f30 ffffffffc062854c ffffffff811a0000 9800000102bf4240[ 149.849488] ffffffffc05b0000 ffffffff80e3a798 000000ff78000000 000000ff78000010[ 149.849500] 0000000000000255 98000001021f7de0 98000001023f0078 ffffffff81434000[ 149.849511] 0000000000000000 0000000000000000 9800000102ae0000 980000025e92ae28[ 149.849523] 0000000000000000 c89b63a7ab338e00 0000000000000001 ffffffff8119dce0[ 149.849535] 000000ff78000010 ffffffff804f3d3c 9800000102a07eb0 0000000000000255[ 149.849546] 0000000000000000 ffffffff8049460c 000000ff78000010 0000000000000255[ 149.849558] ...[ 149.849565] Call Trace:[ 149.849567] [] kvm_vz_vcpu_setup+0xc4/0x328 [kvm][ 149.849586] [] kvm_arch_vcpu_create+0x184/0x228 [kvm][ 149.849605] [] kvm_vm_ioctl+0x64c/0xf28 [kvm][ 149.849623] [] sys_ioctl+0xc8/0x118[ 149.849631] [] syscall_common+0x34/0x58The root cause is the deletion of kvm_mips_commpage_init() leaves vcpu->arch.cop0 NULL. So fix it by making cop0 from a pointer to an embeddedobject.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54261 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Add missing gfx11 MQD manager callbacksmqd_stride function was introduced in commit 2f77b9a242a2("drm/amdkfd: Update MQD management on multi XCC setup")but not assigned for gfx11. Fixes a NULL dereference in debugfs.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54264 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:fs/sysv: Null check to prevent null-ptr-deref bugsb_getblk(inode->i_sb, parent) return a null ptr and taking lock onthat leads to the null-ptr-deref bug.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54276 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nfsd: move init of percpu reply_cache_stats counters back to nfsd_init_netCommit f5f9d4a314da ("nfsd: move reply cache initialization into nfsdstartup") moved the initialization of the reply cache into nfsd startup,but didn't account for the stats counters, which can be accessed beforenfsd is ever started. The result can be a NULL pointer dereference whensomeone accesses /proc/fs/nfsd/reply_cache_stats while nfsd is stillshut down.This is a regression and a user-triggerable oops in the right situation:- non-x86_64 arch- /proc/fs/nfsd is mounted in the namespace- nfsd is not started in the namespace- unprivileged user calls "cat /proc/fs/nfsd/reply_cache_stats"Although this is easy to trigger on some arches (like aarch64), onx86_64, calling this_cpu_ptr(NULL) evidently returns a pointer to thefixed_percpu_data. That struct looks just enough like a newlyinitialized percpu var to allow nfsd_reply_cache_stats_show to accessit without Oopsing.Move the initialization of the per-net+per-cpu reply-cache countersback into nfsd_init_net, while leaving the rest of the reply cacheallocations to be done at nfsd startup time.Kudos to Eirik who did most of the legwork to track this down.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Fix NULL dereference in error handlingSmatch reported:drivers/scsi/qedf/qedf_main.c:3056 qedf_alloc_global_queues()warn: missing unwind goto?At this point in the function, nothing has been allocated so we can returndirectly. In particular the "qedf->global_queues" have not been allocatedso calling qedf_free_global_queues() will lead to a NULL dereference whenwe check if (!gl[i]) and "gl" is NULL.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54291 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vduse: fix NULL pointer dereferencevduse_vdpa_set_vq_affinity callback can be calledwith NULL value as cpu_mask when deleting the vdusedevice.This patch resets virtqueue's IRQ affinity mask valueto set all CPUs instead of dereferencing NULL cpu_mask.[ 4760.952149] BUG: kernel NULL pointer dereference, address: 0000000000000000[ 4760.959110] #PF: supervisor read access in kernel mode[ 4760.964247] #PF: error_code(0x0000) - not-present page[ 4760.969385] PGD 0 P4D 0[ 4760.971927] Oops: 0000 [#1] PREEMPT SMP PTI[ 4760.976112] CPU: 13 PID: 2346 Comm: vdpa Not tainted 6.4.0-rc6+ #4[ 4760.982291] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.8.1 06/26/2020[ 4760.989769] RIP: 0010:memcpy_orig+0xc5/0x130[ 4760.994049] Code: 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 fa 08 72 1b <4c> 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 cc cc cc cc 66[ 4761.012793] RSP: 0018:ffffb1d565abb830 EFLAGS: 00010246[ 4761.018020] RAX: ffff9f4bf6b27898 RBX: ffff9f4be23969c0 RCX: ffff9f4bcadf6400[ 4761.025152] RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff9f4bf6b27898[ 4761.032286] RBP: 0000000000000000 R08: 0000000000000008 R09: 0000000000000000[ 4761.039416] R10: 0000000000000000 R11: 0000000000000600 R12: 0000000000000000[ 4761.046549] R13: 0000000000000000 R14: 0000000000000080 R15: ffffb1d565abbb10[ 4761.053680] FS: 00007f64c2ec2740(0000) GS:ffff9f635f980000(0000) knlGS:0000000000000000[ 4761.061765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 4761.067513] CR2: 0000000000000000 CR3: 0000001875270006 CR4: 00000000007706e0[ 4761.074645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 4761.081775] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 4761.088909] PKRU: 55555554[ 4761.091620] Call Trace:[ 4761.094074] [ 4761.096180] ? __die+0x1f/0x70[ 4761.099238] ? page_fault_oops+0x171/0x4f0[ 4761.103340] ? exc_page_fault+0x7b/0x180[ 4761.107265] ? asm_exc_page_fault+0x22/0x30[ 4761.111460] ? memcpy_orig+0xc5/0x130[ 4761.115126] vduse_vdpa_set_vq_affinity+0x3e/0x50 [vduse][ 4761.120533] virtnet_clean_affinity.part.0+0x3d/0x90 [virtio_net][ 4761.126635] remove_vq_common+0x1a4/0x250 [virtio_net][ 4761.131781] virtnet_remove+0x5d/0x70 [virtio_net][ 4761.136580] virtio_dev_remove+0x3a/0x90[ 4761.140509] device_release_driver_internal+0x19b/0x200[ 4761.145742] bus_remove_device+0xc2/0x130[ 4761.149755] device_del+0x158/0x3e0[ 4761.153245] ? kernfs_find_ns+0x35/0xc0[ 4761.157086] device_unregister+0x13/0x60[ 4761.161010] unregister_virtio_device+0x11/0x20[ 4761.165543] device_release_driver_internal+0x19b/0x200[ 4761.170770] bus_remove_device+0xc2/0x130[ 4761.174782] device_del+0x158/0x3e0[ 4761.178276] ? __pfx_vdpa_name_match+0x10/0x10 [vdpa][ 4761.183336] device_unregister+0x13/0x60[ 4761.187260] vdpa_nl_cmd_dev_del_set_doit+0x63/0xe0 [vdpa]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54296 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migrationFix a goof where KVM tries to grab source vCPUs from the destination VMwhen doing intrahost migration. Grabbing the wrong vCPU not only hosesthe guest, it also crashes the host due to the VMSA pointer being leftNULL. BUG: unable to handle page fault for address: ffffe38687000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151 Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023 RIP: 0010:__free_pages+0x15/0xd0 RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100 RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000 RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000 R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000 R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0 PKRU: 55555554 Call Trace: sev_free_vcpu+0xcb/0x110 [kvm_amd] svm_vcpu_free+0x75/0xf0 [kvm_amd] kvm_arch_vcpu_destroy+0x36/0x140 [kvm] kvm_destroy_vcpus+0x67/0x100 [kvm] kvm_arch_destroy_vm+0x161/0x1d0 [kvm] kvm_put_kvm+0x276/0x560 [kvm] kvm_vm_release+0x25/0x30 [kvm] __fput+0x106/0x280 ____fput+0x12/0x20 task_work_run+0x86/0xb0 do_exit+0x2e3/0x9c0 do_group_exit+0xb1/0xc0 __x64_sys_exit_group+0x1b/0x20 do_syscall_64+0x41/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd CR2: ffffe38687000000

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54299 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: typec: bus: verify partner exists in typec_altmode_attentionSome usb hubs will negotiate DisplayPort Alt mode with the devicebut will then negotiate a data role swap after entering the altmode. The data role swap causes the device to unregister all altmodes, however the usb hub will still send Attention messageseven after failing to reregister the Alt Mode. type_altmode_attentioncurrently does not verify whether or not a device's altmode partnerexists, which results in a NULL pointer error when dereferencingthe typec_altmode and typec_altmode_ops belonging to the altmodepartner.Verify the presence of a device's altmode partner before sendingthe Attention message to the Alt Mode driver.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54304 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:firmware: meson_sm: fix to avoid potential NULL pointer dereferenceof_match_device() may fail and returns a NULL pointer.Fix this by checking the return value of of_match_device.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54313 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ovl: fix null pointer dereference in ovl_get_acl_rcu()Following process: P1 P2 path_openat link_path_walk may_lookup inode_permission(rcu) ovl_permission acl_permission_check check_acl get_cached_acl_rcu ovl_get_inode_acl realinode = ovl_inode_real(ovl_inode) drop_cache __dentry_kill(ovl_dentry) iput(ovl_inode) ovl_destroy_inode(ovl_inode) dput(oi->__upperdentry) dentry_kill(upperdentry) dentry_unlink_inode upperdentry->d_inode = NULL ovl_inode_upper upperdentry = ovl_i_dentry_upper(ovl_inode) d_inode(upperdentry) // returns NULL IS_POSIXACL(realinode) // NULL pointer dereference, will trigger an null pointer dereference at realinode: [ 205.472797] BUG: kernel NULL pointer dereference, address: 0000000000000028 [ 205.476701] CPU: 2 PID: 2713 Comm: ls Not tainted 6.3.0-12064-g2edfa098e750-dirty #1216 [ 205.478754] RIP: 0010:do_ovl_get_acl+0x5d/0x300 [ 205.489584] Call Trace: [ 205.489812] [ 205.490014] ovl_get_inode_acl+0x26/0x30 [ 205.490466] get_cached_acl_rcu+0x61/0xa0 [ 205.490908] generic_permission+0x1bf/0x4e0 [ 205.491447] ovl_permission+0x79/0x1b0 [ 205.491917] inode_permission+0x15e/0x2c0 [ 205.492425] link_path_walk+0x115/0x550 [ 205.493311] path_lookupat.isra.0+0xb2/0x200 [ 205.493803] filename_lookup+0xda/0x240 [ 205.495747] vfs_fstatat+0x7b/0xb0Fetch a reproducer in [Link].Use the helper ovl_i_path_realinode() to get realinode and then donon-nullptr checking.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/powernv/sriov: perform null check on iov before dereferencing iovCurrently pointer iov is being dereferenced before the null check of iovwhich can lead to null pointer dereference errors. Fix this by moving theiov null check before the dereferencing.Detected using cppcheck static analysis:linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Eitherthe condition '!iov' is redundant or there is possible null pointerdereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54319 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: at91-pio4: check return value of devm_kasprintf()devm_kasprintf() returns a pointer to dynamically allocated memory.Pointer could be NULL in case allocation fails. Check pointer validity.Identified with coccinelle (kmerr.cocci script).Depends-on: 1c4e5c470a56 ("pinctrl: at91: use devm_kasprintf() to avoid potential leaks")Depends-on: 5a8f9cf269e8 ("pinctrl: at91-pio4: use proper format specifier for unsigned int")

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glibc < 2.38-150600.14.40.1 (version in image is 2.38-150600.14.37.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40024 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vhost: Take a reference on the task in struct vhost_task.vhost_task_create() creates a task and keeps a reference to itstask_struct. That task may exit early via a signal and its task_structwill be released.A pending vhost_task_wake() will then attempt to wake the task andaccess a task_struct which is no longer there.Acquire a reference on the task_struct while creating the thread andrelease the reference while the struct vhost_task itself is removed.If the task exits early due to a signal, then the vhost_task_wake() willstill access a valid task_struct. The wake is safe and will be skippedin this case.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40033 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:remoteproc: pru: Fix potential NULL pointer dereference in pru_rproc_set_ctable()pru_rproc_set_ctable() accessed rproc->priv before the IS_ERR_OR_NULLcheck, which could lead to a null pointer dereference. Move the pruassignment, ensuring we never dereference a NULL rproc pointer.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40225 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Fix kernel panic on partial unmap of a GPU VA regionThis commit address a kernel panic issue that can happen if Userspacetries to partially unmap a GPU virtual region (aka drm_gpuva).The VM_BIND interface allows partial unmapping of a BO.Panthor driver pre-allocates memory for the new drm_gpuva structuresthat would be needed for the map/unmap operation, done using drm_gpuvmlayer. It expected that only one new drm_gpuva would be needed on umapbut a partial unmap can require 2 new drm_gpuva and that's why itended up doing a NULL pointer dereference causing a kernel panic.Following dump was seen when partial unmap was exercised. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000078 Mem abort info: ESR = 0x0000000096000046 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 = 0x00000046, ISS2 = 0x00000000 CM = 0, WnR = 1, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=000000088a863000 [000000000000078] pgd=080000088a842003, p4d=080000088a842003, pud=0800000884bf5003, pmd=0000000000000000 Internal error: Oops: 0000000096000046 [#1] PREEMPT SMP pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] lr : panthor_gpuva_sm_step_remap+0x6c/0x330 [panthor] sp : ffff800085d43970 x29: ffff800085d43970 x28: ffff00080363e440 x27: ffff0008090c6000 x26: 0000000000000030 x25: ffff800085d439f8 x24: ffff00080d402000 x23: ffff800085d43b60 x22: ffff800085d439e0 x21: ffff00080abdb180 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000010 x17: 6e656c202c303030 x16: 3666666666646466 x15: 393d61766f69202c x14: 312d3d7361203a70 x13: 303030323d6e656c x12: ffff80008324bf58 x11: 0000000000000003 x10: 0000000000000002 x9 : ffff8000801a6a9c x8 : ffff00080360b300 x7 : 0000000000000000 x6 : 000000088aa35fc7 x5 : fff1000080000000 x4 : ffff8000842ddd30 x3 : 0000000000000001 x2 : 0000000100000000 x1 : 0000000000000001 x0 : 0000000000000078 Call trace: panthor_gpuva_sm_step_remap+0xe4/0x330 [panthor] op_remap_cb.isra.22+0x50/0x80 __drm_gpuvm_sm_unmap+0x10c/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xb4/0x3d0 [panthor] panthor_vm_bind_exec_sync_op+0x154/0x278 [panthor] panthor_ioctl_vm_bind+0x160/0x4a0 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x240/0x500 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x40/0xf8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40231 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:vsock: fix lock inversion in vsock_assign_transport()Syzbot reported a potential lock inversion deadlock betweenvsock_register_mutex and sk_lock-AF_VSOCK when vsock_linger() is called.The issue was introduced by commit 687aa0c5581b ("vsock: Fixtransport_* TOCTOU") which added vsock_register_mutex locking invsock_assign_transport() around the transport->release() call, that cancall vsock_linger(). vsock_assign_transport() can be called with sk_lockheld. vsock_linger() calls sk_wait_event() that temporarily releases andre-acquires sk_lock. During this window, if another thread holdvsock_register_mutex while trying to acquire sk_lock, a circulardependency is created.Fix this by releasing vsock_register_mutex before callingtransport->release() and vsock_deassign_transport(). This is safebecause we don't need to hold vsock_register_mutex while releasing theold transport, and we ensure the new transport won't disappear byobtaining a module reference first via try_module_get().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40244 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent()The syzbot reported issue in __hfsplus_ext_cache_extent():[ 70.194323][ T9350] BUG: KMSAN: uninit-value in __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.195022][ T9350] __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.195530][ T9350] hfsplus_file_extend+0x74f/0x1cf0[ 70.195998][ T9350] hfsplus_get_block+0xe16/0x17b0[ 70.196458][ T9350] __block_write_begin_int+0x962/0x2ce0[ 70.196959][ T9350] cont_write_begin+0x1000/0x1950[ 70.197416][ T9350] hfsplus_write_begin+0x85/0x130[ 70.197873][ T9350] generic_perform_write+0x3e8/0x1060[ 70.198374][ T9350] __generic_file_write_iter+0x215/0x460[ 70.198892][ T9350] generic_file_write_iter+0x109/0x5e0[ 70.199393][ T9350] vfs_write+0xb0f/0x14e0[ 70.199771][ T9350] ksys_write+0x23e/0x490[ 70.200149][ T9350] __x64_sys_write+0x97/0xf0[ 70.200570][ T9350] x64_sys_call+0x3015/0x3cf0[ 70.201065][ T9350] do_syscall_64+0xd9/0x1d0[ 70.201506][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.202054][ T9350][ 70.202279][ T9350] Uninit was created at:[ 70.202693][ T9350] __kmalloc_noprof+0x621/0xf80[ 70.203149][ T9350] hfsplus_find_init+0x8d/0x1d0[ 70.203602][ T9350] hfsplus_file_extend+0x6ca/0x1cf0[ 70.204087][ T9350] hfsplus_get_block+0xe16/0x17b0[ 70.204561][ T9350] __block_write_begin_int+0x962/0x2ce0[ 70.205074][ T9350] cont_write_begin+0x1000/0x1950[ 70.205547][ T9350] hfsplus_write_begin+0x85/0x130[ 70.206017][ T9350] generic_perform_write+0x3e8/0x1060[ 70.206519][ T9350] __generic_file_write_iter+0x215/0x460[ 70.207042][ T9350] generic_file_write_iter+0x109/0x5e0[ 70.207552][ T9350] vfs_write+0xb0f/0x14e0[ 70.207961][ T9350] ksys_write+0x23e/0x490[ 70.208375][ T9350] __x64_sys_write+0x97/0xf0[ 70.208810][ T9350] x64_sys_call+0x3015/0x3cf0[ 70.209255][ T9350] do_syscall_64+0xd9/0x1d0[ 70.209680][ T9350] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.210230][ T9350][ 70.210454][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Not tainted 6.12.0-rc5 #5[ 70.211174][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.212115][ T9350] =====================================================[ 70.212734][ T9350] Disabling lock debugging due to kernel taint[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic set ...[ 70.213858][ T9350] CPU: 2 UID: 0 PID: 9350 Comm: repro Tainted: G B 6.12.0-rc5 #5[ 70.214679][ T9350] Tainted: [B]=BAD_PAGE[ 70.215057][ T9350] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.215999][ T9350] Call Trace:[ 70.216309][ T9350] [ 70.216585][ T9350] dump_stack_lvl+0x1fd/0x2b0[ 70.217025][ T9350] dump_stack+0x1e/0x30[ 70.217421][ T9350] panic+0x502/0xca0[ 70.217803][ T9350] ? kmsan_get_metadata+0x13e/0x1c0[ 70.218294][ Message fromT sy9350] kmsan_report+0x296/slogd@syzkaller 0x2aat Aug 18 22:11:058 ... kernel:[ 70.213284][ T9350] Kernel panic - not syncing: kmsan.panic [ 70.220179][ T9350] ? kmsan_get_metadata+0x13e/0x1c0set ...[ 70.221254][ T9350] ? __msan_warning+0x96/0x120[ 70.222066][ T9350] ? __hfsplus_ext_cache_extent+0x7d0/0x990[ 70.223023][ T9350] ? hfsplus_file_extend+0x74f/0x1cf0[ 70.224120][ T9350] ? hfsplus_get_block+0xe16/0x17b0[ 70.224946][ T9350] ? __block_write_begin_int+0x962/0x2ce0[ 70.225756][ T9350] ? cont_write_begin+0x1000/0x1950[ 70.226337][ T9350] ? hfsplus_write_begin+0x85/0x130[ 70.226852][ T9350] ? generic_perform_write+0x3e8/0x1060[ 70.227405][ T9350] ? __generic_file_write_iter+0x215/0x460[ 70.227979][ T9350] ? generic_file_write_iter+0x109/0x5e0[ 70.228540][ T9350] ? vfs_write+0xb0f/0x14e0[ 70.228997][ T9350] ? ksys_write+0x23e/0x490---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40250 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Clean up only new IRQ glue on request_irq() failureThe mlx5_irq_alloc() function can inadvertently free the entire rmapand end up in a crash[1] when the other threads tries to access this,when request_irq() fails due to exhausted IRQ vectors. This commitmodifies the cleanup to remove only the specific IRQ mapping that wasjust added.This prevents removal of other valid mappings and ensures precisecleanup of the failed IRQ allocation's associated glue object.Note: This error is observed when both fwctl and rds configs are enabled.[1]mlx5_core 0000:05:00.0: Successfully registered panic handler for port 1mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:05:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:06:00.0: Successfully registered panic handler for port 1mlx5_core 0000:06:00.0: mlx5_irq_alloc:293:(pid 66740): Failed torequest irq. err = -28infiniband mlx5_0: mlx5_ib_test_wc:290:(pid 66740): Error -28 whiletrying to test write-combining supportmlx5_core 0000:06:00.0: Successfully unregistered panic handler for port 1mlx5_core 0000:03:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28mlx5_core 0000:05:00.0: mlx5_irq_alloc:293:(pid 28895): Failed torequest irq. err = -28general protection fault, probably for non-canonical address0xe277a58fde16f291: 0000 [#1] SMP NOPTIRIP: 0010:free_irq_cpu_rmap+0x23/0x7dCall Trace: ? show_trace_log_lvl+0x1d6/0x2f9 ? show_trace_log_lvl+0x1d6/0x2f9 ? mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] ? __die_body.cold+0x8/0xa ? die_addr+0x39/0x53 ? exc_general_protection+0x1c4/0x3e9 ? dev_vprintk_emit+0x5f/0x90 ? asm_exc_general_protection+0x22/0x27 ? free_irq_cpu_rmap+0x23/0x7d mlx5_irq_alloc.cold+0x5d/0xf3 [mlx5_core] irq_pool_request_vector+0x7d/0x90 [mlx5_core] mlx5_irq_request+0x2e/0xe0 [mlx5_core] mlx5_irq_request_vector+0xad/0xf7 [mlx5_core] comp_irq_request_pci+0x64/0xf0 [mlx5_core] create_comp_eq+0x71/0x385 [mlx5_core] ? mlx5e_open_xdpsq+0x11c/0x230 [mlx5_core] mlx5_comp_eqn_get+0x72/0x90 [mlx5_core] ? xas_load+0x8/0x91 mlx5_comp_irqn_get+0x40/0x90 [mlx5_core] mlx5e_open_channel+0x7d/0x3c7 [mlx5_core] mlx5e_open_channels+0xad/0x250 [mlx5_core] mlx5e_open_locked+0x3e/0x110 [mlx5_core] mlx5e_open+0x23/0x70 [mlx5_core] __dev_open+0xf1/0x1a5 __dev_change_flags+0x1e1/0x249 dev_change_flags+0x21/0x5c do_setlink+0x28b/0xcc4 ? __nla_parse+0x22/0x3d ? inet6_validate_link_af+0x6b/0x108 ? cpumask_next+0x1f/0x35 ? __snmp6_fill_stats64.constprop.0+0x66/0x107 ? __nla_validate_parse+0x48/0x1e6 __rtnl_newlink+0x5ff/0xa57 ? kmem_cache_alloc_trace+0x164/0x2ce rtnl_newlink+0x44/0x6e rtnetlink_rcv_msg+0x2bb/0x362 ? __netlink_sendskb+0x4c/0x6c ? netlink_unicast+0x28f/0x2ce ? rtnl_calcit.isra.0+0x150/0x146 netlink_rcv_skb+0x5f/0x112 netlink_unicast+0x213/0x2ce netlink_sendmsg+0x24f/0x4d9 __sock_sendmsg+0x65/0x6a ____sys_sendmsg+0x28f/0x2c9 ? import_iovec+0x17/0x2b ___sys_sendmsg+0x97/0xe0 __sys_sendmsg+0x81/0xd8 do_syscall_64+0x35/0x87 entry_SYSCALL_64_after_hwframe+0x6e/0x0RIP: 0033:0x7fc328603727Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 0b edff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 44 ed ff ff 48RSP: 002b:00007ffe8eb3f1a0 EFLAGS: 00000293 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc328603727RDX: 0000000000000000 RSI: 00007ffe8eb3f1f0 RDI: 000000000000000dRBP: 00007ffe8eb3f1f0 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000R13: 00000000000---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40256 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:xfrm: also call xfrm_state_delete_tunnel at destroy time for states that were never addedIn commit b441cf3f8c4b ("xfrm: delete x->tunnel as we delete x"), Imissed the case where state creation fails between fullinitialization (->init_state has been called) and being inserted onthe lists.In this situation, ->init_state has been called, so for IPcomptunnels, the fallback tunnel has been created and added onto thelists, but the user state never gets added, because we fail beforethat. The user state doesn't go through __xfrm_state_delete, so wedon't call xfrm_state_delete_tunnel for those states, and we end upleaking the FB tunnel.There are several codepaths affected by this: the add/update paths, inboth net/key and xfrm, and the migrate code (xfrm_migrate,xfrm_state_migrate). A "proper" rollback of the init_state work wouldprobably be doable in the add/update code, but for migrate it getsmore complicated as multiple states may be involved.At some point, the new (not-inserted) state will be destroyed, so callxfrm_state_delete_tunnel during xfrm_state_gc_destroy. Most stateswill have their fallback tunnel cleaned up during __xfrm_state_delete,which solves the issue that b441cf3f8c4b (and other patches before it)aimed at. All states (including FB tunnels) will be removed from thelists once xfrm_state_fini has called flush_work(&xfrm_state_gc_work).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40274 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: guest_memfd: Remove bindings on memslot deletion when gmem is dyingWhen unbinding a memslot from a guest_memfd instance, remove the bindingseven if the guest_memfd file is dying, i.e. even if its file refcount hasgone to zero. If the memslot is freed before the file is fully released,nullifying the memslot side of the binding in kvm_gmem_release() willwrite to freed memory, as detected by syzbot+KASAN: ================================================================== BUG: KASAN: slab-use-after-free in kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 Write of size 8 at addr ffff88807befa508 by task syz.0.17/6022 CPU: 0 UID: 0 PID: 6022 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025 Call 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 kvm_gmem_release+0x176/0x440 virt/kvm/guest_memfd.c:353 __fput+0x44c/0xa70 fs/file_table.c:468 task_work_run+0x1d4/0x260 kernel/task_work.c:227 resume_user_mode_work include/linux/resume_user_mode.h:50 [inline] exit_to_user_mode_loop+0xe9/0x130 kernel/entry/common.c:43 exit_to_user_mode_prepare include/linux/irq-entry-common.h:225 [inline] syscall_exit_to_user_mode_work include/linux/entry-common.h:175 [inline] syscall_exit_to_user_mode include/linux/entry-common.h:210 [inline] do_syscall_64+0x2bd/0xfa0 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7fbeeff8efc9 Allocated by task 6023: 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:397 [inline] __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:414 kasan_kmalloc include/linux/kasan.h:262 [inline] __kmalloc_cache_noprof+0x3e2/0x700 mm/slub.c:5758 kmalloc_noprof include/linux/slab.h:957 [inline] kzalloc_noprof include/linux/slab.h:1094 [inline] kvm_set_memory_region+0x747/0xb90 virt/kvm/kvm_main.c:2104 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 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 Freed by task 6023: 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:584 poison_slab_object mm/kasan/common.c:252 [inline] __kasan_slab_free+0x5c/0x80 mm/kasan/common.c:284 kasan_slab_free include/linux/kasan.h:234 [inline] slab_free_hook mm/slub.c:2533 [inline] slab_free mm/slub.c:6622 [inline] kfree+0x19a/0x6d0 mm/slub.c:6829 kvm_set_memory_region+0x9c4/0xb90 virt/kvm/kvm_main.c:2130 kvm_vm_ioctl_set_memory_region+0x6f/0xd0 virt/kvm/kvm_main.c:2154 kvm_vm_ioctl+0x957/0xc60 virt/kvm/kvm_main.c:5201 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583 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/0x7fDeliberately don't acquire filemap invalid lock when the file is dying asthe lifecycle of f_mapping is outside the purview of KVM. Dereferencingthe mapping is *probably* fine, but there's no need to invalidate anythingas memslot deletion is responsible for zapping SPTEs, and the only codethat can access the dying file is kvm_gmem_release(), whose core code ismutual---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40276 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/panthor: Flush shmem writes before mapping buffers CPU-uncachedThe shmem layer zeroes out the new pages using cached mappings, and ifwe don't CPU-flush we might leave dirty cachelines behind, leading topotential data leaks and/or asynchronous buffer corruption when dirtycachelines are evicted.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40289 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: hide VRAM sysfs attributes on GPUs without VRAMOtherwise accessing them can cause a crash.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:orangefs: fix xattr related buffer overflow...Willy Tarreau forwarded me a message fromDisclosure with the followingwarning:> The helper `xattr_key()` uses the pointer variable in the loop condition> rather than dereferencing it. As `key` is incremented, it remains non-NULL> (until it runs into unmapped memory), so the loop does not terminate on> valid C strings and will walk memory indefinitely, consuming CPU or hanging> the thread.I easily reproduced this with setfattr and getfattr, causing a kerneloops, hung user processes and corrupted orangefs files. Disclosuresent along a diff (not a patch) with a suggested fix, which I basedthis patch on.After xattr_key started working right, xfstest generic/069 exposed anxattr related memory leak that lead to OOM. xattr_key returnsa hashed key. When adding xattrs to the orangefs xattr cache, orangefsused hash_add, a kernel hashing macro. hash_add also hashes the key usinghash_log which resulted in additions to the xattr cache going to the wronghash bucket. generic/069 tortures a single file and orangefs does agetattr for the xattr "security.capability" every time. Orangefsnegative caches on xattrs which includes a kmalloc. Since adds to thexattr cache were going to the wrong bucket, every getattr for"security.capability" resulted in another kmalloc, none of which wereever freed.I changed the two uses of hash_add to hlist_add_head insteadand the memory leak ceased and generic/069 quit throwing furniture.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40308 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: bcsp: receive data only if registeredCurrently, bcsp_recv() can be called even when the BCSP protocol has notbeen registered. This leads to a NULL pointer dereference, as shown inthe following stack trace: KASAN: null-ptr-deref in range [0x0000000000000108-0x000000000000010f] RIP: 0010:bcsp_recv+0x13d/0x1740 drivers/bluetooth/hci_bcsp.c:590 Call Trace: hci_uart_tty_receive+0x194/0x220 drivers/bluetooth/hci_ldisc.c:627 tiocsti+0x23c/0x2c0 drivers/tty/tty_io.c:2290 tty_ioctl+0x626/0xde0 drivers/tty/tty_io.c:2706 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/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/0x7fTo prevent this, ensure that the HCI_UART_REGISTERED flag is set beforeprocessing received data. If the protocol is not registered, return-EUNATCH.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40310 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: resolve a race in amdgpu_amdkfd_device_fini_swThere is race in amdgpu_amdkfd_device_fini_sw and interrupt.if amdgpu_amdkfd_device_fini_sw run in b/w kfd_cleanup_nodes and kfree(kfd), and KGD interrupt generated.kernel panic log:BUG: kernel NULL pointer dereference, address: 0000000000000098amdgpu 0000:c8:00.0: amdgpu: Requesting 4 partitions through PSPPGD d78c68067 P4D d78c68067kfd kfd: amdgpu: Allocated 3969056 bytes on gartPUD 1465b8067 PMD @Oops: @002 [#1] SMP NOPTIkfd kfd: amdgpu: Total number of KFD nodes to be created: 4CPU: 115 PID: @ Comm: swapper/115 Kdump: loaded Tainted: G S W OE KRIP: 0010:_raw_spin_lock_irqsave+0x12/0x40Code: 89 e@ 41 5c c3 cc cc cc cc 66 66 2e Of 1f 84 00 00 00 00 00 OF 1f 40 00 Of 1f 44% 00 00 41 54 9c 41 5c fa 31 cO ba 01 00 00 00 OF b1 17 75 Ba 4c 89 e@ 41 Sc89 c6 e8 07 38 5dRSP: 0018: ffffc90@1a6b0e28 EFLAGS: 00010046RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000000000180000000000000001 RSI: ffff8883bb623e00 RDI: 0000000000000098ffff8883bb000000 RO8: ffff888100055020 ROO: ffff8881000550200000000000000000 R11: 0000000000000000 R12: 0900000000000002ffff888F2b97da0@ R14: @000000000000098 R15: ffff8883babdfo00CS: 010 DS: 0000 ES: 0000 CRO: 0000000080050033CR2: 0000000000000098 CR3: 0000000e7cae2006 CR4: 0000000002770ce00000000000000000 DR1: 0000000000000000 DR2: 00000000000000000000000000000000 DR6: 00000000fffeO7FO DR7: 0000000000000400PKRU: 55555554Call Trace:kgd2kfd_interrupt+@x6b/0x1f@ [amdgpu]? amdgpu_fence_process+0xa4/0x150 [amdgpu]kfd kfd: amdgpu: Node: 0, interrupt_bitmap: 3 YcpxFl Rant tEraceamdgpu_irq_dispatch+0x165/0x210 [amdgpu]amdgpu_ih_process+0x80/0x100 [amdgpu]amdgpu: Virtual CRAT table created for GPUamdgpu_irq_handler+0x1f/@x60 [amdgpu]__handle_irq_event_percpu+0x3d/0x170amdgpu: Topology: Add dGPU node [0x74a2:0x1002]handle_irq_event+0x5a/@xcOhandle_edge_irq+0x93/0x240kfd kfd: amdgpu: KFD node 1 partition @ size 49148Masm_call_irq_on_stack+0xf/@x20common_interrupt+0xb3/0x130asm_common_interrupt+0x1le/0x405.10.134-010.a1i5000.a18.x86_64 #1

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40312 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: Verify inode mode when loading from diskThe inode mode loaded from corrupted disk can be invalid. Do like whatcommit 0a9e74051313 ("isofs: Verify inode mode when loading from disk")does.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40315 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Fix epfile null pointer access after ep enable.A race condition occurs when ffs_func_eps_enable() runs concurrentlywith ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()sets ffs->epfiles to NULL before resetting ffs->eps_count to 0, leadingto a NULL pointer dereference when accessing epfile->ep inffs_func_eps_enable() after successful usb_ep_enable().The ffs->epfiles pointer is set to NULL in both ffs_data_clear() andffs_data_close() functions, and its modification is protected by thespinlock ffs->eps_lock. And the whole ffs_func_eps_enable() functionis also protected by ffs->eps_lock.Thus, add NULL pointer handling for ffs->epfiles in theffs_func_eps_enable() function to fix issues

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40316 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Fix device use-after-free on unbindA recent change fixed device reference leaks when looking up drmplatform device driver data during bind() but failed to remove a partialfix which had been added by commit 80805b62ea5b ("drm/mediatek: Fixkobject put for component sub-drivers").This results in a reference imbalance on component bind() failures andon unbind() which could lead to a user-after-free.Make sure to only drop the references after retrieving the driver databy effectively reverting the previous partial fix.Note that holding a reference to a device does not prevent its driverdata from going away so there is no point in keeping the reference.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40318 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sync: fix race in hci_cmd_sync_dequeue_oncehci_cmd_sync_dequeue_once() does lookup and then cancelthe entry under two separate lock sections. Meanwhile,hci_cmd_sync_work() can also delete the same entry,leading to double list_del() and "UAF".Fix this by holding cmd_sync_work_lock across bothlookup and cancel, so that the entry cannot be removedconcurrently.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40320 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential cfid UAF in smb2_query_info_compoundWhen smb2_query_info_compound() retries, a previously allocated cfid mayhave been freed in the first attempt.Because cfid wasn't reset on replay, later cleanup could act on a stalepointer, leading to a potential use-after-free.Reinitialize cfid to NULL under the replay label.Example trace (trimmed):refcount_t: underflow; use-after-free.WARNING: CPU: 1 PID: 11224 at ../lib/refcount.c:28 refcount_warn_saturate+0x9c/0x110[...]RIP: 0010:refcount_warn_saturate+0x9c/0x110[...]Call Trace: smb2_query_info_compound+0x29c/0x5c0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? step_into+0x10d/0x690 ? __legitimize_path+0x28/0x60 smb2_queryfs+0x6a/0xf0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] smb311_queryfs+0x12d/0x140 [cifs f90b72658819bd21c94769b6a652029a07a7172f] ? kmem_cache_alloc+0x18a/0x340 ? getname_flags+0x46/0x1e0 cifs_statfs+0x9f/0x2b0 [cifs f90b72658819bd21c94769b6a652029a07a7172f] statfs_by_dentry+0x67/0x90 vfs_statfs+0x16/0xd0 user_statfs+0x54/0xa0 __do_sys_statfs+0x20/0x50 do_syscall_64+0x58/0x80

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40329 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cbThe Mesa issue referenced below pointed out a possible deadlock:[ 1231.611031] Possible interrupt unsafe locking scenario:[ 1231.611033] CPU0 CPU1[ 1231.611034] ---- ----[ 1231.611035] lock(&xa->xa_lock#17);[ 1231.611038] local_irq_disable();[ 1231.611039] lock(&fence->lock);[ 1231.611041] lock(&xa->xa_lock#17);[ 1231.611044] [ 1231.611045] lock(&fence->lock);[ 1231.611047] *** DEADLOCK ***In this example, CPU0 would be any function accessing job->dependenciesthrough the xa_* functions that don't disable interrupts (eg:drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signallingcallback so in an interrupt context. It will deadlock when trying tograb the xa_lock which is already held by CPU0.Replacing all xa_* usage by their xa_*_irq counterparts would fixthis issue, but Christian pointed out another issue: dma_fence_signaltakes fence.lock and so does dma_fence_add_callback. dma_fence_signal() // locks f1.lock -> drm_sched_entity_kill_jobs_cb() -> foreach dependencies -> dma_fence_add_callback() // locks f2.lockThis will deadlock if f1 and f2 share the same spinlock.To fix both issues, the code iterating on dependencies and re-arming themis moved out to drm_sched_entity_kill_jobs_work().[phasta: commit message nits]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40330 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Shutdown FW DMA in bnxt_shutdown()The netif_close() call in bnxt_shutdown() only stops packet DMA. Theremay be FW DMA for trace logging (recently added) that will continue. Ifwe kexec to a new kernel, the DMA will corrupt memory in the new kernel.Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.This will stop the FW DMA. In case the call fails, call pcie_flr() toreset the function and stop the DMA.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: Fix mmap write lock not releaseIf mmap write lock is taken while draining retry fault, mmap write lockis not released because svm_range_restore_pages calls mmap_read_unlockthen returns. This causes deadlock and system hangs later because mmapread or write lock cannot be taken.Downgrade mmap write lock to read lock if draining retry fault fix thisbug.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40349 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfs: validate record offset in hfsplus_bmap_allochfsplus_bmap_alloc can trigger a crash if arecord offset or length is larger than node_size[ 15.264282] BUG: KASAN: slab-out-of-bounds in hfsplus_bmap_alloc+0x887/0x8b0[ 15.265192] Read of size 8 at addr ffff8881085ca188 by task test/183[ 15.265949][ 15.266163] CPU: 0 UID: 0 PID: 183 Comm: test Not tainted 6.17.0-rc2-gc17b750b3ad9 #14 PREEMPT(voluntary)[ 15.266165] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 15.266167] Call Trace:[ 15.266168] [ 15.266169] dump_stack_lvl+0x53/0x70[ 15.266173] print_report+0xd0/0x660[ 15.266181] kasan_report+0xce/0x100[ 15.266185] hfsplus_bmap_alloc+0x887/0x8b0[ 15.266208] hfs_btree_inc_height.isra.0+0xd5/0x7c0[ 15.266217] hfsplus_brec_insert+0x870/0xb00[ 15.266222] __hfsplus_ext_write_extent+0x428/0x570[ 15.266225] __hfsplus_ext_cache_extent+0x5e/0x910[ 15.266227] hfsplus_ext_read_extent+0x1b2/0x200[ 15.266233] hfsplus_file_extend+0x5a7/0x1000[ 15.266237] hfsplus_get_block+0x12b/0x8c0[ 15.266238] __block_write_begin_int+0x36b/0x12c0[ 15.266251] block_write_begin+0x77/0x110[ 15.266252] cont_write_begin+0x428/0x720[ 15.266259] hfsplus_write_begin+0x51/0x100[ 15.266262] cont_write_begin+0x272/0x720[ 15.266270] hfsplus_write_begin+0x51/0x100[ 15.266274] generic_perform_write+0x321/0x750[ 15.266285] generic_file_write_iter+0xc3/0x310[ 15.266289] __kernel_write_iter+0x2fd/0x800[ 15.266296] dump_user_range+0x2ea/0x910[ 15.266301] elf_core_dump+0x2a94/0x2ed0[ 15.266320] vfs_coredump+0x1d85/0x45e0[ 15.266349] get_signal+0x12e3/0x1990[ 15.266357] arch_do_signal_or_restart+0x89/0x580[ 15.266362] irqentry_exit_to_user_mode+0xab/0x110[ 15.266364] asm_exc_page_fault+0x26/0x30[ 15.266366] RIP: 0033:0x41bd35[ 15.266367] Code: bc d1 f3 0f 7f 27 f3 0f 7f 6f 10 f3 0f 7f 77 20 f3 0f 7f 7f 30 49 83 c0 0f 49 29 d0 48 8d 7c 17 31 e9 9f 0b 00 00 66 0f ef c0 0f 6f 0e f3 0f 6f 56 10 66 0f 74 c1 66 0f d7 d0 49 83 f8f[ 15.266369] RSP: 002b:00007ffc9e62d078 EFLAGS: 00010283[ 15.266371] RAX: 00007ffc9e62d100 RBX: 0000000000000000 RCX: 0000000000000000[ 15.266372] RDX: 00000000000000e0 RSI: 0000000000000000 RDI: 00007ffc9e62d100[ 15.266373] RBP: 0000400000000040 R08: 00000000000000e0 R09: 0000000000000000[ 15.266374] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000[ 15.266375] R13: 0000000000000000 R14: 0000000000000000 R15: 0000400000000000[ 15.266376] When calling hfsplus_bmap_alloc to allocate a free node, this functionfirst retrieves the bitmap from header node and map node using node->pagetogether with the offset and length from hfs_brec_lenoff```len = hfs_brec_lenoff(node, 2, &off16);off = off16;off += node->page_offset;pagep = node->page + (off >> PAGE_SHIFT);data = kmap_local_page(*pagep);```However, if the retrieved offset or length is invalid(i.e. exceedsnode_size), the code may end up accessing pages outside the allocatedrange for this node.This patch adds proper validation of both offset and length before use,preventing out-of-bounds page access. Move is_bnode_offset_valid andcheck_and_correct_requested_length to hfsplus_fs.h, as they may berequired by other functions.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40351 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:hfsplus: fix KMSAN uninit-value issue in hfsplus_delete_cat()The syzbot reported issue in hfsplus_delete_cat():[ 70.682285][ T9333] =====================================================[ 70.682943][ T9333] BUG: KMSAN: uninit-value in hfsplus_subfolders_dec+0x1d7/0x220[ 70.683640][ T9333] hfsplus_subfolders_dec+0x1d7/0x220[ 70.684141][ T9333] hfsplus_delete_cat+0x105d/0x12b0[ 70.684621][ T9333] hfsplus_rmdir+0x13d/0x310[ 70.685048][ T9333] vfs_rmdir+0x5ba/0x810[ 70.685447][ T9333] do_rmdir+0x964/0xea0[ 70.685833][ T9333] __x64_sys_rmdir+0x71/0xb0[ 70.686260][ T9333] x64_sys_call+0xcd8/0x3cf0[ 70.686695][ T9333] do_syscall_64+0xd9/0x1d0[ 70.687119][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.687646][ T9333][ 70.687856][ T9333] Uninit was stored to memory at:[ 70.688311][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0[ 70.688779][ T9333] hfsplus_create_cat+0x148e/0x1800[ 70.689231][ T9333] hfsplus_mknod+0x27f/0x600[ 70.689730][ T9333] hfsplus_mkdir+0x5a/0x70[ 70.690146][ T9333] vfs_mkdir+0x483/0x7a0[ 70.690545][ T9333] do_mkdirat+0x3f2/0xd30[ 70.690944][ T9333] __x64_sys_mkdir+0x9a/0xf0[ 70.691380][ T9333] x64_sys_call+0x2f89/0x3cf0[ 70.691816][ T9333] do_syscall_64+0xd9/0x1d0[ 70.692229][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.692773][ T9333][ 70.692990][ T9333] Uninit was stored to memory at:[ 70.693469][ T9333] hfsplus_subfolders_inc+0x1c2/0x1d0[ 70.693960][ T9333] hfsplus_create_cat+0x148e/0x1800[ 70.694438][ T9333] hfsplus_fill_super+0x21c1/0x2700[ 70.694911][ T9333] mount_bdev+0x37b/0x530[ 70.695320][ T9333] hfsplus_mount+0x4d/0x60[ 70.695729][ T9333] legacy_get_tree+0x113/0x2c0[ 70.696167][ T9333] vfs_get_tree+0xb3/0x5c0[ 70.696588][ T9333] do_new_mount+0x73e/0x1630[ 70.697013][ T9333] path_mount+0x6e3/0x1eb0[ 70.697425][ T9333] __se_sys_mount+0x733/0x830[ 70.697857][ T9333] __x64_sys_mount+0xe4/0x150[ 70.698269][ T9333] x64_sys_call+0x2691/0x3cf0[ 70.698704][ T9333] do_syscall_64+0xd9/0x1d0[ 70.699117][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.699730][ T9333][ 70.699946][ T9333] Uninit was created at:[ 70.700378][ T9333] __alloc_pages_noprof+0x714/0xe60[ 70.700843][ T9333] alloc_pages_mpol_noprof+0x2a2/0x9b0[ 70.701331][ T9333] alloc_pages_noprof+0xf8/0x1f0[ 70.701774][ T9333] allocate_slab+0x30e/0x1390[ 70.702194][ T9333] ___slab_alloc+0x1049/0x33a0[ 70.702635][ T9333] kmem_cache_alloc_lru_noprof+0x5ce/0xb20[ 70.703153][ T9333] hfsplus_alloc_inode+0x5a/0xd0[ 70.703598][ T9333] alloc_inode+0x82/0x490[ 70.703984][ T9333] iget_locked+0x22e/0x1320[ 70.704428][ T9333] hfsplus_iget+0x5c/0xba0[ 70.704827][ T9333] hfsplus_btree_open+0x135/0x1dd0[ 70.705291][ T9333] hfsplus_fill_super+0x1132/0x2700[ 70.705776][ T9333] mount_bdev+0x37b/0x530[ 70.706171][ T9333] hfsplus_mount+0x4d/0x60[ 70.706579][ T9333] legacy_get_tree+0x113/0x2c0[ 70.707019][ T9333] vfs_get_tree+0xb3/0x5c0[ 70.707444][ T9333] do_new_mount+0x73e/0x1630[ 70.707865][ T9333] path_mount+0x6e3/0x1eb0[ 70.708270][ T9333] __se_sys_mount+0x733/0x830[ 70.708711][ T9333] __x64_sys_mount+0xe4/0x150[ 70.709158][ T9333] x64_sys_call+0x2691/0x3cf0[ 70.709630][ T9333] do_syscall_64+0xd9/0x1d0[ 70.710053][ T9333] entry_SYSCALL_64_after_hwframe+0x77/0x7f[ 70.710611][ T9333][ 70.710842][ T9333] CPU: 3 UID: 0 PID: 9333 Comm: repro Not tainted 6.12.0-rc6-dirty #17[ 70.711568][ T9333] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014[ 70.712490][ T9333] =====================================================[ 70.713085][ T9333] Disabling lock debugging due to kernel taint[ 70.713618][ T9333] Kernel panic - not syncing: kmsan.panic set ...[ 70.714159][ T9333] ---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40354 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: increase max link count and fix link->enc NULL pointer access[why]1.) dc->links[MAX_LINKS] array size smaller than actual requested.max_connector + max_dpia + 4 virtual = 14.increase from 12 to 14.2.) hw_init() access null LINK_ENC for dpia non display_endpoint.(cherry picked from commit d7f5a61e1b04ed87b008c8d327649d184dc5bb45)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40360 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/sysfb: Do not dereference NULL pointer in plane resetThe plane state in __drm_gem_reset_shadow_plane() can be NULL. Do notderef that pointer, but forward NULL to the other plane-reset helpers.Clears plane->state to NULL.v2:- fix typo in commit description (Javier)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68168 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:jfs: fix uninitialized waitqueue in transaction managerThe transaction manager initialization in txInit() was not properlyinitializing TxBlock[0].waitor waitqueue, causing a crash whentxEnd(0) is called on read-only filesystems.When a filesystem is mounted read-only, txBegin() returns tid=0 toindicate no transaction. However, txEnd(0) still gets called andtries to access TxBlock[0].waitor via tid_to_tblock(0), but thiswaitqueue was never initialized because the initialization loopstarted at index 1 instead of 0.This causes a 'non-static key' lockdep warning and system crash: INFO: trying to register non-static key in txEndFix by ensuring all transaction blocks including TxBlock[0] havetheir waitqueues properly initialized during txInit().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68170 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Do not kfree() devres managed rdevSince the allocation of the drivers main structure was changed todevm_drm_dev_alloc() rdev is managed by devres and we shouldn't be callingkfree() on it.This fixes things exploding if the driver probe fails and devres cleans upthe rdev after we already free'd it.(cherry picked from commit 16c0681617b8a045773d4d87b6140002fa75b03b)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68172 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:crypto: aspeed - fix double free caused by devmThe clock obtained via devm_clk_get_enabled() is automatically managedby devres and will be disabled and freed on driver detach. Manuallycalling clk_disable_unprepare() in error path and remove functioncauses double free.Remove the manual clock cleanup in both aspeed_acry_probe()'s errorpath and aspeed_acry_remove().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68180 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix NULL deref in debugfs odm_combine_segmentsWhen a connector is connected but inactive (e.g., disabled by desktopenvironments), pipe_ctx->stream_res.tg will be destroyed. Then, readingodm_combine_segments causes kernel NULL pointer dereference. 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: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy) e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6 Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025 RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554 Call Trace: seq_read_iter+0x125/0x490 ? __alloc_frozen_pages_noprof+0x18f/0x350 seq_read+0x12c/0x170 full_proxy_read+0x51/0x80 vfs_read+0xbc/0x390 ? __handle_mm_fault+0xa46/0xef0 ? do_syscall_64+0x71/0x900 ksys_read+0x73/0xf0 do_syscall_64+0x71/0x900 ? count_memcg_events+0xc2/0x190 ? handle_mm_fault+0x1d7/0x2d0 ? do_user_addr_fault+0x21a/0x690 ? exc_page_fault+0x7e/0x1a0 entry_SYSCALL_64_after_hwframe+0x6c/0x74 RIP: 0033:0x7f44d4031687 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> RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000 RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687 RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003 RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000 Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x> snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn> platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp> CR2: 0000000000000000 ---[ end trace 0000000000000000 ]--- RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu] Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00> RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286 RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8 RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000 RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0 R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08 R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001 FS: 00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0 PKRU: 55555554Fix this by checking pipe_ctx->---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68181 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/radeon: Remove calls to drm_put_dev()Since the allocation of the drivers main structure was changed todevm_drm_dev_alloc() drm_put_dev()'ing to trigger it to be free'dshould be done by devres.However, drm_put_dev() is still in the probe error and device removepaths. When the driver fails to probe warnings like the following areshown because devres is trying to drm_put_dev() after the driveralready did it.[ 5.642230] radeon 0000:01:05.0: probe with driver radeon failed with error -22[ 5.649605] ------------[ cut here ]------------[ 5.649607] refcount_t: underflow; use-after-free.[ 5.649620] WARNING: CPU: 0 PID: 357 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110(cherry picked from commit 3eb8c0b4c091da0a623ade0d3ee7aa4a93df1ea4)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68184 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Disable AFBC support on Mediatek DRM driverCommit c410fa9b07c3 ("drm/mediatek: Add AFBC support to Mediatek DRMdriver") added AFBC support to Mediatek DRM and enabled the32x8/split/sparse modifier.However, this is currently broken on Mediatek MT8188 (Genio 700 EVKplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used bydefault since Mesa v25.0.Kernel trace reports vblank timeouts constantly, and the render is garbled:```[CRTC:62:crtc-0] vblank wait timed outWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c[...]Hardware name: MediaTek Genio-700 EVK (DT)Workqueue: events_unbound commit_workpstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27clr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27csp : ffff80008337bca0x29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000x26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000x23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80x20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000ax17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000x14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206bx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70x8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70x5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480Call trace: drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P) drm_atomic_helper_commit_tail_rpm+0x64/0x80 commit_tail+0xa4/0x1a4 commit_work+0x14/0x20 process_one_work+0x150/0x290 worker_thread+0x2d0/0x3ec kthread+0x12c/0x210 ret_from_fork+0x10/0x20---[ end trace 0000000000000000 ]---```Until this gets fixed upstream, disable AFBC support on this platform, asit's currently broken with upstream Mesa.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68190 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()kcalloc() may fail. When WS is non-zero and allocation fails, ectx.wsremains NULL while ectx.ws_size is set, leading to a potential NULLpointer dereference in atom_get_src_int() when accessing WS entries.Return -ENOMEM on allocation failure to avoid the NULL dereference.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68194 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:media: imon: make send_packet() more robustsyzbot is reporting that imon has three problems which result inhung tasks due to forever holding device lock [1].First problem is that when usb_rx_callback_intf0() once got -EPROTO errorafter ictx->dev_present_intf0 became true, usb_rx_callback_intf0()resubmits urb after printk(), and resubmitted urb causesusb_rx_callback_intf0() to again get -EPROTO error. This results inprintk() flooding (RCU stalls).Alan Stern commented [2] that In theory it's okay to resubmit _if_ the driver has a robust error-recovery scheme (such as giving up after some fixed limit on the number of errors or after some fixed time has elapsed, perhaps with a time delay to prevent a flood of errors). Most drivers don't bother to do this; they simply give up right away. This makes them more vulnerable to short-term noise interference during USB transfers, but in reality such interference is quite rare. There's nothing really wrong with giving up right away.but imon has a poor error-recovery scheme which just retries forever;this behavior should be fixed.Since I'm not sure whether it is safe for imon users to give up upon anyerror code, this patch takes care of only union of error codes chosen frommodules in drivers/media/rc/ directory which handle -EPROTO error (i.e.ir_toy, mceusb and igorplugusb).Second problem is that when usb_rx_callback_intf0() once got -EPROTO errorbefore ictx->dev_present_intf0 becomes true, usb_rx_callback_intf0() alwaysresubmits urb due to commit 8791d63af0cf ("[media] imon: don't wedgehardware after early callbacks"). Move the ictx->dev_present_intf0 testintroduced by commit 6f6b90c9231a ("[media] imon: don't parse scancodesuntil intf configured") to immediately before imon_incoming_packet(), orthe first problem explained above happens without printk() flooding (i.e.hung task).Third problem is that when usb_rx_callback_intf0() is not called for somereason (e.g. flaky hardware; the reproducer for this problem sometimesprevents usb_rx_callback_intf0() from being called),wait_for_completion_interruptible() in send_packet() never returns (i.e.hung task). As a workaround for such situation, change send_packet() towait for completion with timeout of 10 seconds.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68195 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:x86/CPU/AMD: Add missing terminator for zen5_rdseed_microcodeRunning x86_match_min_microcode_rev() on a Zen5 CPU trips up KASAN for an outof bounds access.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68197 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bnxt_en: Fix null pointer dereference in bnxt_bs_trace_check_wrap()With older FW, we may get the ASYNC_EVENT_CMPL_EVENT_ID_DBG_BUF_PRODUCERfor FW trace data type that has not been initialized. This will resultin a crash in bnxt_bs_trace_type_wrap(). Add a guard to check for avalid magic_byte pointer before proceeding.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68207 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/xe/guc: Synchronize Dead CT worker with unbindCancel and wait for any Dead CT worker to complete before continuingwith device unbinding. Else the worker will end up using resources freedby the undind operation.(cherry picked from commit 492671339114e376aaa38626d637a2751cdef263)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68209 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mlx5: Fix default values in create CQCurrently, CQs without a completion function are assigned themlx5_add_cq_to_tasklet function by default. This is problematic sinceonly user CQs created through the mlx5_ib driver are intended to usethis function.Additionally, all CQs that will use doorbells instead of polling forcompletions must call mlx5_cq_arm. However, the default CQ creation flowleaves a valid value in the CQ's arm_db field, allowing FW to sendinterrupts to polling-only CQs in certain corner cases.These two factors would allow a polling-only kernel CQ to be triggeredby an EQ interrupt and call a completion function intended only for userCQs, causing a null pointer exception.Some areas in the driver have prevented this issue with one-off fixesbut did not address the root cause.This patch fixes the described issue by adding defaults to the create CQflow. It adds a default dummy completion function to protect againstnull pointer exceptions, and it sets an invalid command sequence numberby default in kernel CQs to prevent the FW from sending an interrupt tothe CQ until it is armed. User CQs are responsible for their owninitialization values.Callers of mlx5_core_create_cq are responsible for changing thecompletion function and arming the CQ per their needs.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68217 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Input: pegasus-notetaker - fix potential out-of-bounds accessIn the pegasus_notetaker driver, the pegasus_probe() function allocatesthe URB transfer buffer using the wMaxPacketSize value fromthe endpoint descriptor. An attacker can use a malicious USB descriptorto force the allocation of a very small buffer.Subsequently, if the device sends an interrupt packet with a specificpattern (e.g., where the first byte is 0x80 or 0x42),the pegasus_parse_packet() function parses the packet without checkingthe allocated buffer size. This leads to an out-of-bounds memory access.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68218 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nvme-multipath: fix lockdep WARN due to partition scan workBlktests test cases nvme/014, 057 and 058 fail occasionally due to alockdep WARN. As reported in the Closes tag URL, the WARN indicates thata deadlock can happen due to the dependency among disk->open_mutex,kblockd workqueue completion and partition_scan_work completion.To avoid the lockdep WARN and the potential deadlock, cut the dependencyby running the partition_scan_work not by kblockd workqueue but bynvme_wq.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68222 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:pinctrl: s32cc: fix uninitialized memory in s32_pinctrl_descs32_pinctrl_desc is allocated with devm_kmalloc(), but not all of itsfields are initialized. Notably, num_custom_params is used inpinconf_generic_parse_dt_config(), resulting in intermittent allocationerrors, such as the following splat when probing i2c-imx: WARNING: CPU: 0 PID: 176 at mm/page_alloc.c:4795 __alloc_pages_noprof+0x290/0x300 [...] Hardware name: NXP S32G3 Reference Design Board 3 (S32G-VNP-RDB3) (DT) [...] Call trace: __alloc_pages_noprof+0x290/0x300 (P) ___kmalloc_large_node+0x84/0x168 __kmalloc_large_node_noprof+0x34/0x120 __kmalloc_noprof+0x2ac/0x378 pinconf_generic_parse_dt_config+0x68/0x1a0 s32_dt_node_to_map+0x104/0x248 dt_to_map_one_config+0x154/0x1d8 pinctrl_dt_to_map+0x12c/0x280 create_pinctrl+0x6c/0x270 pinctrl_get+0xc0/0x170 devm_pinctrl_get+0x50/0xa0 pinctrl_bind_pins+0x60/0x2a0 really_probe+0x60/0x3a0 [...] __platform_driver_register+0x2c/0x40 i2c_adap_imx_init+0x28/0xff8 [i2c_imx] [...]This results in later parse failures that can cause issues in dependentdrivers: s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c0-pins/i2c0-grp0: could not parse node property [...] pca953x 0-0022: failed writing register: -6 i2c i2c-0: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c2-pins/i2c2-grp0: could not parse node property i2c i2c-1: IMX I2C adapter registered s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property s32g-siul2-pinctrl 4009c240.pinctrl: /soc@0/pinctrl@4009c240/i2c4-pins/i2c4-grp0: could not parse node property i2c i2c-2: IMX I2C adapter registeredFix this by initializing s32_pinctrl_desc with devm_kzalloc() instead ofdevm_kmalloc() in s32_pinctrl_probe(), which sets the previouslyuninitialized fields to zero.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68230 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix gpu page fault after hibernation on PF passthroughOn PF passthrough environment, after hibernate and then resume, coralgemmwill cause gpu page fault.Mode1 reset happens during hibernate, but partition mode is not restoredon resume, register mmCP_HYP_XCP_CTL and mmCP_PSP_XCP_CTL is not rightafter resume. When CP access the MQD BO, wrong stride size is used,this will cause out of bound access on the MQD BO, resulting page fault.The fix is to ensure gfx_v9_4_3_switch_compute_partition() is calledwhen resume from a hibernation.KFD resume is called separately during a reset recovery or resume fromsuspend sequence. Hence it's not required to be called as part ofpartition switch.(cherry picked from commit 5d1b32cfe4a676fe552416cb5ae847b215463a1a)

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68233 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:drm/tegra: Add call to put_pid()Add a call to put_pid() corresponding to get_task_pid().host1x_memory_context_alloc() does not take ownership of the PID so weneed to free it here to avoid leaking.[mperttunen@nvidia.com: reword commit message]

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68235 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:nouveau/firmware: Add missing kfree() of nvkm_falcon_fw::bootnvkm_falcon_fw::boot is allocated, but no one frees it. This causes akmemleak warning.Make sure this data is deallocated.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68237 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtdchar: fix integer overflow in read/write ioctlsThe "req.start" and "req.len" variables are u64 values that come from theuser at the start of the function. We mask away the high 32 bits of"req.len" so that's capped at U32_MAX but the "req.start" variable can goup to U64_MAX which means that the addition can still integer overflow.Use check_add_overflow() to fix this bug.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68238 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:mtd: rawnand: cadence: fix DMA device NULL pointer dereferenceThe DMA device pointer `dma_dev` was being dereferenced before ensuringthat `cdns_ctrl->dmac` is properly initialized.Move the assignment of `dma_dev` after successfully acquiring the DMAchannel to ensure the pointer is valid before use.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68252 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix dma_buf object leak in fastrpc_map_lookupIn fastrpc_map_lookup, dma_buf_get is called to obtain a reference tothe dma_buf for comparison purposes. However, this reference is neverreleased when the function returns, leading to a dma_buf memory leak.Fix this by adding dma_buf_put before returning from the function,ensuring that the temporarily acquired reference is properly releasedregardless of whether a matching map is found.Rule: add

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68259 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:KVM: SVM: Don't skip unrelated instruction if INT3/INTO is replacedWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTninstruction, discard the exception and retry the instruction if the codestream is changed (e.g. by a different vCPU) between when the CPUexecutes the instruction and when KVM decodes the instruction to get thenext RIP.As effectively predicted by commit 6ef88d6e36c2 ("KVM: SVM: Re-injectINT3/INTO instead of retrying the instruction"), failure to verify thatthe correct INTn instruction was decoded can effectively clobber gueststate due to decoding the wrong instruction and thus specifying thewrong next RIP.The bug most often manifests as "Oops: int3" panics on static branchchecks in Linux guests. Enabling or disabling a static branch in Linuxuses the kernel's "text poke" code patching mechanism. To modify codewhile other CPUs may be executing that code, Linux (temporarily)replaces the first byte of the original instruction with an int3 (opcode0xcc), then patches in the new code stream except for the first byte,and finally replaces the int3 with the first byte of the new codestream. If a CPU hits the int3, i.e. executes the code while it's beingmodified, then the guest kernel must look up the RIP to determine how tohandle the #BP, e.g. by emulating the new instruction. If the RIP isincorrect, then this lookup fails and the guest kernel panics.The bug reproduces almost instantly by hacking the guest kernel torepeatedly check a static branch[1] while running a drgn script[2] onthe host to constantly swap out the memory containing the guest's TSS.[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68298 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: mediatek: Avoid btusb_mtk_claim_iso_intf() NULL derefIn btusb_mtk_setup(), we set `btmtk_data->isopkt_intf` to: usb_ifnum_to_if(data->udev, MTK_ISO_IFNUM)That function can return NULL in some cases. Even when it returnsNULL, though, we still go on to call btusb_mtk_claim_iso_intf().As of commit e9087e828827 ("Bluetooth: btusb: mediatek: Add locks forusb_driver_claim_interface()"), calling btusb_mtk_claim_iso_intf()when `btmtk_data->isopkt_intf` is NULL will cause a crash becausewe'll end up passing a bad pointer to device_lock(). Prior to thatcommit we'd pass the NULL pointer directly tousb_driver_claim_interface() which would detect it and return anerror, which was handled.Resolve the crash in btusb_mtk_claim_iso_intf() by adding a NULL checkat the start of the function. This makes the code handle a NULL`btmtk_data->isopkt_intf` the same way it did before the problematiccommit (just with a slight change to the error message printed).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68305 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_sock: Prevent race in socket write iter and sock bindThere is a potential race condition between sock bind and socket writeiter. bind may free the same cmd via mgmt_pending before write iter sendsthe cmd, just as syzbot reported in UAF[1].Here we use hci_dev_lock to synchronize the two, thereby avoiding theUAF mentioned in [1].[1]syzbot reported:BUG: KASAN: slab-use-after-free in mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316Read of size 8 at addr ffff888077164818 by task syz.0.17/5989Call Trace: mgmt_pending_remove+0x3b/0x210 net/bluetooth/mgmt_util.c:316 set_link_security+0x5c2/0x710 net/bluetooth/mgmt.c:1918 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Allocated by task 5989: mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296 set_link_security+0x557/0x710 net/bluetooth/mgmt.c:1910 hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719 hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839 sock_sendmsg_nosec net/socket.c:727 [inline] __sock_sendmsg+0x21c/0x270 net/socket.c:742 sock_write_iter+0x279/0x360 net/socket.c:1195Freed by task 5991: mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline] mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257 mgmt_index_removed+0x112/0x2f0 net/bluetooth/mgmt.c:9477 hci_sock_bind+0xbe9/0x1000 net/bluetooth/hci_sock.c:1314

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68306 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interfaceWhen performing reset tests and encountering abnormal card drop issuesthat lead to a kernel crash, it is necessary to perform a null checkbefore releasing resources to avoid attempting to release a null pointer.<4>[ 29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)<4>[ 29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]<4>[ 29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<4>[ 29.158162] pc : klist_remove+0x90/0x158<4>[ 29.158174] lr : klist_remove+0x88/0x158<4>[ 29.158180] sp : ffffffc0846b3c00<4>[ 29.158185] pmr_save: 000000e0<4>[ 29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058<4>[ 29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0<4>[ 29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290<4>[ 29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781<4>[ 29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428<4>[ 29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018<4>[ 29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000<4>[ 29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d<4>[ 29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e<4>[ 29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c<4>[ 29.158285] Call trace:<4>[ 29.158290] klist_remove+0x90/0x158<4>[ 29.158298] device_release_driver_internal+0x20c/0x268<4>[ 29.158308] device_release_driver+0x1c/0x30<4>[ 29.158316] usb_driver_release_interface+0x70/0x88<4>[ 29.158325] btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]<4>[ 29.158347] btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]<4>[ 29.158361] hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]<4>[ 29.158430] process_scheduled_works+0x258/0x4e8<4>[ 29.158441] worker_thread+0x300/0x428<4>[ 29.158448] kthread+0x108/0x1d0<4>[ 29.158455] ret_from_fork+0x10/0x20<0>[ 29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)<4>[ 29.158474] ---[ end trace 0000000000000000 ]---<0>[ 29.167129] Kernel panic - not syncing: Oops: Fatal exception<2>[ 29.167144] SMP: stopping secondary CPUs<4>[ 29.167158] ------------[ cut here ]------------

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68332 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: c6xdigio: Fix invalid PNP driver unregistrationThe Comedi low-level driver "c6xdigio" seems to be for a parallel portconnected device. When the Comedi core calls the driver's Comedi"attach" handler `c6xdigio_attach()` to configure a Comedi to use thisdriver, it tries to enable the parallel port PNP resources byregistering a PNP driver with `pnp_register_driver()`, but ignores thereturn value. (The `struct pnp_driver` it uses has only the `name` and`id_table` members filled in.) The driver's Comedi "detach" handler`c6xdigio_detach()` unconditionally unregisters the PNP driver with`pnp_unregister_driver()`.It is possible for `c6xdigio_attach()` to return an error before itcalls `pnp_register_driver()` and it is possible for the call to`pnp_register_driver()` to return an error (that is ignored). In bothcases, the driver should not be calling `pnp_unregister_driver()` as itdoes in `c6xdigio_detach()`. (Note that `c6xdigio_detach()` will becalled by the Comedi core if `c6xdigio_attach()` returns an error, or ifthe Comedi core decides to detach the Comedi device from the driver forsome other reason.)The unconditional call to `pnp_unregister_driver()` without a previoussuccessful call to `pnp_register_driver()` will cause`driver_unregister()` to issue a warning "Unexpected driverunregister!". This was detected by Syzbot [1].Also, the PNP driver registration and unregistration should be done atmodule init and exit time, respectively, not when attaching or detachingComedi devices to the driver. (There might be more than one Comedidevice being attached to the driver, although that is unlikely.)Change the driver to do the PNP driver registration at module init time,and the unregistration at module exit time. Since `c6xdigio_detach()`now only calls `comedi_legacy_detach()`, remove the function and changethe Comedi driver "detach" handler to `comedi_legacy_detach`.-------------------------------------------[1] Syzbot sample crash report:Unexpected driver unregister!WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister drivers/base/driver.c:273 [inline]WARNING: CPU: 0 PID: 5970 at drivers/base/driver.c:273 driver_unregister+0x90/0xb0 drivers/base/driver.c:270Modules linked in:CPU: 0 UID: 0 PID: 5970 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/02/2025RIP: 0010:driver_unregister drivers/base/driver.c:273 [inline]RIP: 0010:driver_unregister+0x90/0xb0 drivers/base/driver.c:270Code: 48 89 ef e8 c2 e6 82 fc 48 89 df e8 3a 93 ff ff 5b 5d e9 c3 6d d9 fb e8 be 6d d9 fb 90 48 c7 c7 e0 f8 1f 8c e8 51 a2 97 fb 90 <0f> 0b 90 90 5b 5d e9 a5 6d d9 fb e8 e0 f4 41 fc eb 94 e8 d9 f4 41RSP: 0018:ffffc9000373f9a0 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffffffff8ff24720 RCX: ffffffff817b6ee8RDX: ffff88807c932480 RSI: ffffffff817b6ef5 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000001 R12: ffffffff8ff24660R13: dffffc0000000000 R14: 0000000000000000 R15: ffff88814cca0000FS: 000055556dab1500(0000) GS:ffff8881249d9000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000055f77f285cd0 CR3: 000000007d871000 CR4: 00000000003526f0Call Trace: comedi_device_detach_locked+0x12f/0xa50 drivers/comedi/drivers.c:207 comedi_device_detach+0x67/0xb0 drivers/comedi/drivers.c:215 comedi_device_attach+0x43d/0x900 drivers/comedi/drivers.c:1011 do_devconfig_ioctl+0x1b1/0x710 drivers/comedi/comedi_fops.c:872 comedi_unlocked_ioctl+0x165d/0x2f00 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline] __se_sys_ioctl fs/ioctl.c:583 [inline] __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_sys---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68335 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems fromthe fact that in case of early device detach via pcl818_detach(),subdevice dev->read_subdev may not have initialized its pointer to&struct comedi_async as intended. Thus, any such dereferencing of&s->async->cmd will lead to general protection fault and kernel crash.Mitigate this problem by removing a call to pcl818_ai_cancel() frompcl818_detach() altogether. This way, if the subdevice setups itssupport for async commands, everything async-related will behandled via subdevice's own ->cancel() function incomedi_device_detach_locked() even before pcl818_detach(). If nosupport for asynchronous commands is provided, there is no needto cancel anything either.[1] Syzbot crash:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762...Call Trace: pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115 comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207 do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline] comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:597 [inline]...

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68351 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:exfat: fix refcount leak in exfat_findFix refcount leaks in `exfat_find` related to `exfat_get_dentry_set`.Function `exfat_get_dentry_set` would increase the reference counter of`es->bh` on success. Therefore, `exfat_put_dentry_set` must be calledafter `exfat_get_dentry_set` to ensure refcount consistency. This patchrelocate two checks to avoid possible leaks.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68378 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check in __bpf_get_stackid()Syzkaller reported a KASAN slab-out-of-bounds write in __bpf_get_stackid()when copying stack trace data. The issue occurs when the perf trace contains more stack entries than the stack map bucket can hold, leading to an out-of-bounds write in the bucket's data array.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68380 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix peer HE MCS assignmentIn ath11k_wmi_send_peer_assoc_cmd(), peer's transmit MCS is sent tofirmware as receive MCS while peer's receive MCS sent as transmit MCS,which goes against firmwire's definition.While connecting to a misbehaved AP that advertises 0xffff (meaning notsupported) for 160 MHz transmit MCS map, firmware crashes due to 0xffffis assigned to he_mcs->rx_mcs_set field. Ext Tag: HE Capabilities [...] Supported HE-MCS and NSS Set [...] Rx and Tx MCS Maps 160 MHz [...] Tx HE-MCS Map 160 MHz: 0xffffSwap the assignment to fix this issue.As the HE rate control mask is meant to limit our own transmit MCS, itneeds to go via he_mcs->rx_mcs_set field. With the aforementioned swappingdone, change is needed as well to apply it to the peer's receive MCS.Tested-on: WCN6855 hw2.1 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68734 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:isdn: mISDN: hfcsusb: fix memory leak in hfcsusb_probe()In hfcsusb_probe(), the memory allocated for ctrl_urb gets leaked whensetup_instance() fails with an error code. Fix that by freeing the urbbefore freeing the hw structure. Also change the error paths to use thegoto ladder style.Compile tested only. Issue found using a prototype static analysis tool.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68753 Severity: Moderate CVSS3 score: 5.5

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: firewire-motu: add bounds check in put_user loop for DSP eventsIn the DSP event handling code, a put_user() loop copies event data.When the user buffer size is not aligned to 4 bytes, it could overwritebeyond the buffer boundary.Fix by adding a bounds check before put_user().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).

CVE-2026-23553 Severity: Moderate CVSS3 score: 5.5

Description: In the context switch logic Xen attempts to skip an IBPB in the case ofa vCPU returning to a CPU on which it was the previous vCPU to run.While safe for Xen's isolation between vCPUs, this prevents the guestkernel correctly isolating between tasks. Consider: 1) vCPU runs on CPU A, running task 1. 2) vCPU moves to CPU B, idle gets scheduled on A. Xen skips IBPB. 3) On CPU B, guest kernel switches from task 1 to 2, issuing IBPB. 4) vCPU moves back to CPU A. Xen skips IBPB again.Now, task 2 is running on CPU A with task 1's training still in the BTB.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
xen-libs < 4.20.2_04-150700.3.22.1 (version in image is 4.20.2_02-150700.3.19.1).

CVE-2026-24515 Severity: Moderate CVSS3 score: 5.5

Description: In libexpat before 2.7.4, XML_ExternalEntityParserCreate does not copy unknown encoding handler user data.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libsqlite3-0 > 0-0 (version in image is 3.50.2-150000.3.33.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-47911 Severity: Moderate CVSS3 score: 5.3

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).

CVE-2025-58150 Severity: Moderate CVSS3 score: 5.3

Description: Shadow mode tracing code uses a set of per-CPU variables to avoidcumbersome parameter passing. Some of these variables are written towith guest controlled data, of guest controllable size. That size canbe larger than the variable, and bounding of the writes was missing.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
xen-libs < 4.20.2_04-150700.3.22.1 (version in image is 4.20.2_02-150700.3.19.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.1).

CVE-2025-58190 Severity: Moderate CVSS3 score: 5.3

Description: Unknown.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

CVE-2025-68307 Severity: Moderate CVSS3 score: 5.3

Description: In the Linux kernel, the following vulnerability has been resolved:can: gs_usb: gs_usb_xmit_callback(): fix handling of failed transmitted URBsThe driver lacks the cleanup of failed transfers of URBs. This reduces thenumber of available URBs per error by 1. This leads to reduced performanceand ultimately to a complete stop of the transmission.If the sending of a bulk URB fails do proper cleanup:- increase netdev stats- mark the echo_sbk as free- free the driver's context and do accounting- wake the send queue

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
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:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311-aiohttp > 0-0 (version in image is 3.9.3-150400.10.33.1).

CVE-2025-69418 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: When using the low-level OCB API directly with AES-NI or
other hardware-accelerated code paths, inputs whose length is not a multiple
of 16 bytes can leave the final partial block unencrypted and unauthenticated.

Impact summary: The trailing 1-15 bytes of a message may be exposed in
cleartext on encryption and are not covered by the authentication tag,
allowing an attacker to read or tamper with those bytes without detection.

The low-level OCB encrypt and decrypt routines in the hardware-accelerated
stream path process full 16-byte blocks but do not advance the input/output
pointers. The subsequent tail-handling code then operates on the original
base pointers, effectively reprocessing the beginning of the buffer while
leaving the actual trailing bytes unprocessed. The authentication checksum
also excludes the true tail bytes.

However, typical OpenSSL consumers using EVP are not affected because the
higher-level EVP and provider OCB implementations split inputs so that full
blocks and trailing partial blocks are processed in separate calls, avoiding
the problematic code path. Additionally, TLS does not use OCB ciphersuites.
The vulnerability only affects applications that call the low-level
CRYPTO_ocb128_encrypt() or CRYPTO_ocb128_decrypt() functions directly with
non-block-aligned lengths in a single call on hardware-accelerated builds.
For these reasons the issue was assessed as Low severity.

The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected
by this issue, as OCB mode is not a FIPS-approved algorithm.

OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.

OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.1).

CVE-2025-69420 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A type confusion vulnerability exists in the TimeStamp Responseverification code where an ASN1_TYPE union member is accessed without firstvalidating the type, causing an invalid or NULL pointer dereference whenprocessing a malformed TimeStamp Response file.Impact summary: An application calling TS_RESP_verify_response() with amalformed TimeStamp Response can be caused to dereference an invalid orNULL pointer when reading, resulting in a Denial of Service.The functions ossl_ess_get_signing_cert() and ossl_ess_get_signing_cert_v2()access the signing cert attribute value without validating its type.When the type is not V_ASN1_SEQUENCE, this results in accessing invalid memorythrough the ASN1_TYPE union, causing a crash.Exploiting this vulnerability requires an attacker to provide a malformedTimeStamp Response to an application that verifies timestamp responses. TheTimeStamp protocol (RFC 3161) is not widely used and the impact of theexploit is just a Denial of Service. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the TimeStamp Response implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.OpenSSL 1.0.2 is not affected by this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
vim > 0-0 (version in image is 9.1.1629-150500.20.38.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glibc < 2.38-150600.14.40.1 (version in image is 2.38-150600.14.37.1).

CVE-2026-22796 Severity: Moderate CVSS3 score: 5.3

Description: Issue summary: A type confusion vulnerability exists in the signatureverification of signed PKCS#7 data where an ASN1_TYPE union member isaccessed without first validating the type, causing an invalid or NULLpointer dereference when processing malformed PKCS#7 data.Impact summary: An application performing signature verification of PKCS#7data or calling directly the PKCS7_digest_from_attributes() function can becaused to dereference an invalid or NULL pointer when reading, resulting ina Denial of Service.The function PKCS7_digest_from_attributes() accesses the message digest attributevalue without validating its type. When the type is not V_ASN1_OCTET_STRING,this results in accessing invalid memory through the ASN1_TYPE union, causinga crash.Exploiting this vulnerability requires an attacker to provide a malformedsigned PKCS#7 to an application that verifies it. The impact of theexploit is just a Denial of Service, the PKCS7 API is legacy and applicationsshould be using the CMS API instead. For these reasons the issue wasassessed as Low severity.The FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,as the PKCS#7 parsing implementation is outside the OpenSSL FIPS moduleboundary.OpenSSL 3.6, 3.5, 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are vulnerable to this issue.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libopenssl1_1 < 1.1.1w-150700.11.11.1 (version in image is 1.1.1w-150700.11.6.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40338 Severity: Moderate CVSS3 score: 5.2

Description: In the Linux kernel, the following vulnerability has been resolved:ASoC: Intel: avs: Do not share the name pointer between componentsBy sharing 'name' directly, tearing down components may lead touse-after-free errors. Duplicate the name to avoid that.At the same time, update the order of operations - since commitcee28113db17 ("ASoC: dmaengine_pcm: Allow passing component name viaconfig") the framework does not override component->name if set beforeinvoking the initializer.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-53777 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:erofs: kill hooked chains to avoid loops on deduplicated compressed imagesAfter heavily stressing EROFS with several images which include ahand-crafted image of repeated patterns for more than 46 days, I foundtwo chains could be linked with each other almost simultaneously andform a loop so that the entire loop won't be submitted. As aconsequence, the corresponding file pages will remain locked forever.It can be _only_ observed on data-deduplicated compressed images.For example, consider two chains with five pclusters in total: Chain 1: 2->3->4->5 -- The tail pcluster is 5; Chain 2: 5->1->2 -- The tail pcluster is 2.Chain 2 could link to Chain 1 with pcluster 5; and Chain 1 could linkto Chain 2 at the same time with pcluster 2.Since hooked chains are all linked locklessly now, I have no idea howto simply avoid the race. Instead, let's avoid hooked chains completelyuntil I could work out a proper way to fix this and end users finallytell us that it's needed to add it back.Actually, this optimization can be found with multi-threaded workloads(especially even more often on deduplicated compressed images), yet I'mnot sure about the overall system impacts of not having this comparedwith implementation complexity.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54072 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ALSA: pcm: Fix potential data race at PCM memory allocation helpersThe PCM memory allocation helpers have a sanity check against too manybuffer allocations. However, the check is performed without a properlock and the allocation isn't serialized; this allows user to allocatemore memories than predefined max size.Practically seen, this isn't really a big problem, as it's more orless some "soft limit" as a sanity check, and it's not possible toallocate unlimitedly. But it's still better to address this for moreconsistent behavior.The patch covers the size check in do_alloc_pages() with thecard->memory_mutex, and increases the allocated size there forpreventing the further overflow. When the actual allocation fails,the size is decreased accordingly.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54115 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db()When nonstatic_release_resource_db() frees all resources associatedwith an PCMCIA socket, it forgets to free socket_data too, causinga memory leak observable with kmemleak:unreferenced object 0xc28d1000 (size 64): comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00 ................ 00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmem_cache_alloc_node+0x2d7/0x4a0 [<7e51f0c8>] kmalloc_trace+0x31/0xa4 [] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc] [] pcmcia_register_socket+0x200/0x35c [pcmcia_core] [] yenta_probe+0x4d8/0xa70 [yenta_socket] [] pci_device_probe+0x99/0x194 [<84b7c690>] really_probe+0x181/0x45c [<8060fe6e>] __driver_probe_device+0x75/0x1f4 [] driver_probe_device+0x28/0xac [<648b766f>] __driver_attach+0xeb/0x1e4 [<6e9659eb>] bus_for_each_dev+0x61/0xb4 [<25a669f3>] driver_attach+0x1e/0x28 [] bus_add_driver+0x102/0x20c [] driver_register+0x5b/0x120 [<942cd8a4>] __pci_register_driver+0x44/0x4c [] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support]Fix this by freeing socket_data too.Tested on a Acer Travelmate 4002WLMi by manually binding/unbindingthe yenta_cardbus driver (yenta_socket).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54133 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:nfp: clean mc addresses in application firmware when closing portWhen moving devices from one namespace to another, mc addresses arecleaned in software while not removed from application firmware. Thusthe mc addresses are remained and will cause resource leak.Now use `__dev_mc_unsync` to clean mc addresses when closing port.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54136 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:serial: sprd: Fix DMA buffer leak issueRelease DMA buffer when _probe() returns failure to avoid memory leak.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54143 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: fix resource leaks in vdec_msg_queue_init()If we encounter any error in the vdec_msg_queue_init() then we needto set "msg_queue->wdma_addr.size = 0;". Normally, this is doneinside the vdec_msg_queue_deinit() function. However, if thefirst call to allocate &msg_queue->wdma_addr fails, then thevdec_msg_queue_deinit() function is a no-op. For that situation, justset the size to zero explicitly and return.There were two other error paths which did not clean up before returning.Change those error paths to goto mem_alloc_err.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54154 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:scsi: target: core: Fix target_cmd_counter leakThe target_cmd_counter struct allocated via target_alloc_cmd_counter() isnever freed, resulting in leaks across various transport types, e.g.: unreferenced object 0xffff88801f920120 (size 96): comm "sh", pid 102, jiffies 4294892535 (age 713.412s) hex dump (first 32 bytes): 07 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 38 01 92 1f 80 88 ff ff ........8....... backtrace: [<00000000e58a6252>] kmalloc_trace+0x11/0x20 [<0000000043af4b2f>] target_alloc_cmd_counter+0x17/0x90 [target_core_mod] [<000000007da2dfa7>] target_setup_session+0x2d/0x140 [target_core_mod] [<0000000068feef86>] tcm_loop_tpg_nexus_store+0x19b/0x350 [tcm_loop] [<000000006a80e021>] configfs_write_iter+0xb1/0x120 [<00000000e9f4d860>] vfs_write+0x2e4/0x3c0 [<000000008143433b>] ksys_write+0x80/0xb0 [<00000000a7df29b2>] do_syscall_64+0x42/0x90 [<0000000053f45fb8>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8Free the structure alongside the corresponding iscsit_conn / se_sessparent.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54166 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:igc: Fix Kernel Panic during ndo_tx_timeout callbackThe Xeon validation group has been carrying out some loaded testswith various HW configurations, and they have seen some transmitqueue time out happening during the test. This will cause thereset adapter function to be called by igc_tx_timeout().Similar race conditions may arise when the interface is being broughtdown and up in igc_reinit_locked(), an interrupt being generated, andigc_clean_tx_irq() being called to complete the TX.When the igc_tx_timeout() function is invoked, this patch will turnoff all TX ring HW queues during igc_down() process. TX ring HW queueswill be activated again during the igc_configure_tx_ring() processwhen performing the igc_up() procedure later.This patch also moved existing igc_disable_tx_ring_hw() to avoid usingforward declaration.Kernel trace:[ 7678.747813] ------------[ cut here ]------------[ 7678.757914] NETDEV WATCHDOG: enp1s0 (igc): transmit queue 2 timed out[ 7678.770117] WARNING: CPU: 0 PID: 13 at net/sched/sch_generic.c:525 dev_watchdog+0x1ae/0x1f0[ 7678.784459] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE xt_addrtype nft_compatnf_tables nfnetlink br_netfilter bridge stp llc overlay dm_mod emrcha(PO) emriio(PO) rktpm(PO)cegbuf_mod(PO) patch_update(PO) se(PO) sgx_tgts(PO) mktme(PO) keylocker(PO) svtdx(PO) svfs_pci_hotplug(PO)vtd_mod(PO) davemem(PO) svmabort(PO) svindexio(PO) usbx2(PO) ehci_sched(PO) svheartbeat(PO) ioapic(PO)sv8259(PO) svintr(PO) lt(PO) pcierootport(PO) enginefw_mod(PO) ata(PO) smbus(PO) spiflash_cdf(PO) arden(PO)dsa_iax(PO) oobmsm_punit(PO) cpm(PO) svkdb(PO) ebg_pch(PO) pch(PO) sviotargets(PO) svbdf(PO) svmem(PO)svbios(PO) dram(PO) svtsc(PO) targets(PO) superio(PO) svkernel(PO) cswitch(PO) mcf(PO) pentiumIII_mod(PO)fs_svfs(PO) mdevdefdb(PO) svfs_os_services(O) ixgbe mdio mdio_devres libphy emeraldrapids_svdefs(PO)regsupport(O) libnvdimm nls_cp437 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intelsnd_intel_dspcfg snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core snd_pcm snd_timer isst_if_mbox_pci[ 7678.784496] input_leds isst_if_mmio sg snd isst_if_common soundcore wmi button sad9(O) drm fuse backlightconfigfs efivarfs ip_tables x_tables vmd sdhci led_class rtl8150 r8152 hid_generic pegasus mmc_block usbhidmmc_core hid megaraid_sas ixgb igb i2c_algo_bit ice i40e hpsa scsi_transport_sas e1000e e1000 e100 ax88179_178ausbnet xhci_pci sd_mod xhci_hcd t10_pi crc32c_intel crc64_rocksoft igc crc64 crc_t10dif usbcorecrct10dif_generic ptp crct10dif_common usb_common pps_core[ 7679.200403] RIP: 0010:dev_watchdog+0x1ae/0x1f0[ 7679.210201] Code: 28 e9 53 ff ff ff 4c 89 e7 c6 05 06 42 b9 00 01 e8 17 d1 fb ff 44 89 e9 4c89 e6 48 c7 c7 40 ad fb 81 48 89 c2 e8 52 62 82 ff <0f> 0b e9 72 ff ff ff 65 8b 05 80 7d 7c 7e89 c0 48 0f a3 05 0a c1[ 7679.245438] RSP: 0018:ffa00000001f7d90 EFLAGS: 00010282[ 7679.256021] RAX: 0000000000000000 RBX: ff11000109938440 RCX: 0000000000000000[ 7679.268710] RDX: ff11000361e26cd8 RSI: ff11000361e1b880 RDI: ff11000361e1b880[ 7679.281314] RBP: ffa00000001f7da8 R08: ff1100035f8fffe8 R09: 0000000000027ffb[ 7679.293840] R10: 0000000000001f0a R11: ff1100035f840000 R12: ff11000109938000[ 7679.306276] R13: 0000000000000002 R14: dead000000000122 R15: ffa00000001f7e18[ 7679.318648] FS: 0000000000000000(0000) GS:ff11000361e00000(0000) knlGS:0000000000000000[ 7679.332064] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 7679.342757] CR2: 00007ffff7fca168 CR3: 000000013b08a006 CR4: 0000000000471ef8[ 7679.354984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 7679.367207] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400[ 7679.379370] PKRU: 55555554[ 7679.386446] Call Trace:[ 7679.393152] [ 7679.399363] ? __pfx_dev_watchdog+0x10/0x10[ 7679.407870] call_timer_fn+0x31/0x110[ 7679.415698] e---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54183 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: v4l2-core: Fix a potential resource leak in v4l2_fwnode_parse_link()If fwnode_graph_get_remote_endpoint() fails, 'fwnode' is known to be NULL,so fwnode_handle_put() is a no-op.Release the reference taken from a previous fwnode_graph_get_port_parent()call instead.Also handle fwnode_graph_get_port_parent() failures.In order to fix these issues, add an error handling path to the functionand the needed gotos.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54209 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:block: fix blktrace debugfs entries leakageCommit 99d055b4fd4b ("block: remove per-disk debugfs files inblk_unregister_queue") moves blk_trace_shutdown() fromblk_release_queue() to blk_unregister_queue(), this is safe if blktraceis created through sysfs, however, there is a regression in cornercase.blktrace can still be enabled after del_gendisk() through ioctl ifthe disk is opened before del_gendisk(), and if blktrace is not shutdownthrough ioctl before closing the disk, debugfs entries will be leaked.Fix this problem by shutdown blktrace in disk_release(), this is safebecause blk_trace_remove() is reentrant.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54215 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:virtio-vdpa: Fix cpumask memory leak in virtio_vdpa_find_vqs()Free the cpumask allocated by create_affinity_masks() before returningfrom the function.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54230 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:amba: bus: fix refcount leakcommit 5de1540b7bc4 ("drivers/amba: create devices from device tree")increases the refcount of of_node, but not releases it inamba_device_release, so there is refcount leak. By using of_node_putto avoid refcount leak.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54235 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:PCI/DOE: Fix destroy_work_on_stack() raceThe following debug object splat was observed in testing: ODEBUG: free active (active state 0) object: 0000000097d23782 object type: work_struct hint: doe_statemachine_work+0x0/0x510 WARNING: CPU: 1 PID: 71 at lib/debugobjects.c:514 debug_print_object+0x7d/0xb0 ... Workqueue: pci 0000:36:00.0 DOE [1 doe_statemachine_work RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? debug_print_object+0x7d/0xb0 ? __pfx_doe_statemachine_work+0x10/0x10 debug_object_free.part.0+0x11b/0x150 doe_statemachine_work+0x45e/0x510 process_one_work+0x1d4/0x3c0This occurs because destroy_work_on_stack() was called after signalingthe completion in the calling thread. This creates a race betweendestroy_work_on_stack() and the task->work struct going out of scope inpci_doe().Signal the work complete after destroying the work struct. This is safebecause signal_task_complete() is the final thing the work item does andthe workqueue code is careful not to access the work struct after.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54266 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb: m920x: Fix a potential memory leak in m920x_i2c_xfer()'read' is freed when it is known to be NULL, but not when a read erroroccurs.Revert the logic to avoid a small leak, should a m920x_read() call fail.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54326 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:misc: pci_endpoint_test: Free IRQs before removing the deviceIn pci_endpoint_test_remove(), freeing the IRQs after removing the devicecreates a small race window for IRQs to be received with the test devicememory already released, causing the IRQ handler to access invalid memory,resulting in an oops.Free the device IRQs before removing the device to avoid this issue.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40179 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:ext4: verify orphan file size is not too bigIn principle orphan file can be arbitrarily large. However orphan replayneeds to traverse it all and we also pin all its buffers in memory. Thusfilesystems with absurdly large orphan files can lead to big amounts ofmemory consumed. Limit orphan file size to a sane value and also usekvmalloc() for allocating array of block descriptor structures to avoidlarge order allocations for sane but large orphan files.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68749 Severity: Moderate CVSS3 score: 4.7

Description: In the Linux kernel, the following vulnerability has been resolved:accel/ivpu: Fix race condition when unbinding BOsFix 'Memory manager not clean during takedown' warning that occurswhen ivpu_gem_bo_free() removes the BO from the BOs list before itgets unmapped. Then file_priv_unbind() triggers a warning indrm_mm_takedown() during context teardown.Protect the unmapping sequence with bo_list_lock to ensure the BO isalways fully unmapped when removed from the list. This ensures the BOis either fully unmapped at context teardown time or present on thelist and unmapped by file_priv_unbind().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-11065 Severity: Moderate CVSS3 score: 4.5

Description: A flaw was found in github.com/go-viper/mapstructure/v2, in the field processing component using mapstructure.WeakDecode. This vulnerability allows information disclosure through detailed error messages that may leak sensitive input values via malformed user-supplied data processed in security-critical contexts.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
docker > 0-0 (version in image is 28.5.1_ce-150000.238.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54219 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Revert "IB/isert: Fix incorrect release of isert connection"Commit: 699826f4e30a ("IB/isert: Fix incorrect release of isert connection") iscausing problems on OPA when DEVICE_REMOVAL is happening. ------------[ cut here ]------------ WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfcscsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_filerpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfsrfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_modopa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cmib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_corex86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdtipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdmaintel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meteracpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmulcrc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahcighash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1 Hardware name: Intel Corporation S2600CWR/S2600CW, BIOSSE5C610.86B.01.01.0014.121820151719 12/18/2015 RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core] Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83c4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a190 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206 RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640 RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18 R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38 FS: 00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0 Call Trace: ? __warn+0x80/0x130 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] ? report_bug+0x195/0x1a0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core] disable_device+0x9d/0x160 [ib_core] __ib_unregister_device+0x42/0xb0 [ib_core] ib_unregister_device+0x22/0x30 [ib_core] rvt_unregister_device+0x20/0x90 [rdmavt] hfi1_unregister_ib_device+0x16/0xf0 [hfi1] remove_one+0x55/0x1a0 [hfi1] pci_device_remove+0x36/0xa0 device_release_driver_internal+0x193/0x200 driver_detach+0x44/0x90 bus_remove_driver+0x69/0xf0 pci_unregister_driver+0x2a/0xb0 hfi1_mod_cleanup+0xc/0x3c [hfi1] __do_sys_delete_module.constprop.0+0x17a/0x2f0 ? exit_to_user_mode_prepare+0xc4/0xd0 ? syscall_trace_enter.constprop.0+0x126/0x1a0 do_syscall_64+0x5c/0x90 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? syscall_exit_work+0x103/0x130 ? syscall_exit_to_user_mode+0x12/0x30 ? do_syscall_64+0x69/0x90 ? exc_page_fault+0x65/0x150 entry_SYSCALL_64_after_hwframe+0x6e/0xd8 RIP: 0033:0x7ff1e643f5ab Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c366 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8 RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000 R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8 R13: 00000000000---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54278 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:s390/vmem: split pages when debug pagealloc is enabledSince commit bb1520d581a3 ("s390/mm: start kernel with DAT enabled")the kernel crashes early during boot when debug pagealloc is enabled:mem auto-init: stack:off, heap alloc:off, heap free:offaddressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOCModules linked in:CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630[..]Krnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e 00000000001325fc: eb880002000c srlg %r8,%r8,2 #0000000000132602: b2210051 ipte %r5,%r1,%r0,0 >0000000000132606: b90400d1 lgr %r13,%r1 000000000013260a: 41605008 la %r6,8(%r5) 000000000013260e: a7db1000 aghi %r13,4096 0000000000132612: b221006d ipte %r6,%r13,%r0,0 0000000000132616: e3d0d0000171 lay %r13,4096(%r13)Call Trace: __kernel_map_pages+0x14e/0x320 __free_pages_ok+0x23a/0x5a8) free_low_memory_core_early+0x214/0x2c8 memblock_free_all+0x28/0x58 mem_init+0xb6/0x228 mm_core_init+0xb6/0x3b0 start_kernel+0x1d2/0x5a8 startup_continue+0x36/0x40Kernel panic - not syncing: Fatal exception: panic_on_oopsThis is caused by using large mappings on machines with EDAT1/EDAT2. Addthe code to split the mappings into 4k pages if debug pagealloc is enabledby CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernelcommand line option.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-38321 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:smb: Log an error when close_all_cached_dirs failsUnder low-memory conditions, close_all_cached_dirs() can't move thedentries to a separate list to dput() them once the locks are dropped.This will result in a "Dentry still in use" error, so add an errormessage that makes it clear this is what happened:[ 495.281119] CIFS: VFS: \\otters.example.com\share Out of memory while dropping dentries[ 495.281595] ------------[ cut here ]------------[ 495.281887] BUG: Dentry ffff888115531138{i=78,n=/} still in use (2) [unmount of cifs cifs][ 495.282391] WARNING: CPU: 1 PID: 2329 at fs/dcache.c:1536 umount_check+0xc8/0xf0Also, bail out of looping through all tcons as soon as a singleallocation fails, since we're already in trouble, and kmalloc() attemptsfor subseqeuent tcons are likely to fail just like the first one did.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40293 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:iommufd: Don't overflow during division for dirty trackingIf pgshift is 63 then BITS_PER_TYPE(*bitmap->bitmap) * pgsize will overflowto 0 and this triggers divide by 0.In this case the index should just be 0, so reorganize things to divideby shift and avoid hitting any overflows.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40294 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: MGMT: Fix OOB access in parse_adv_monitor_pattern()In the parse_adv_monitor_pattern() function, the value ofthe 'length' variable is currently limited to HCI_MAX_EXT_AD_LENGTH(251).The size of the 'value' array in the mgmt_adv_pattern structure is 31.If the value of 'pattern[i].length' is set in the user spaceand exceeds 31, the 'patterns[i].value' array can be accessedout of bound when copied.Increasing the size of the 'value' array inthe 'mgmt_adv_pattern' structure will break the userspace.Considering this, and to avoid OOB access revert the limits for 'offset'and 'length' back to the value of HCI_MAX_AD_LENGTH.Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with SVACE.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40301 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_event: validate skb length for unknown CC opcodeIn hci_cmd_complete_evt(), if the command complete event has an unknownopcode, we assume the first byte of the remaining skb->data contains thereturn status. However, parameter data has previously been pulled inhci_event_func(), which may leave the skb empty. If so, using skb->data[0]for the return status uses un-init memory.The fix is to check skb->len before using skb->data.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40339 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix nullptr err of vm_handle_movedIf a amdgpu_bo_va is fpriv->prt_va, the bo of this one is always NULL.So, such kind of amdgpu_bo_va should be updated separately beforeamdgpu_vm_handle_moved.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-68744 Severity: Moderate CVSS3 score: 4.4

Description: In the Linux kernel, the following vulnerability has been resolved:bpf: Free special fields when update [lru_,]percpu_hash mapsAs [lru_,]percpu_hash maps support BPF_KPTR_{REF,PERCPU}, missingcalls to 'bpf_obj_free_fields()' in 'pcpu_copy_value()' could cause thememory referenced by BPF_KPTR_{REF,PERCPU} fields to be held until themap gets freed.Fix this by calling 'bpf_obj_free_fields()' after'copy_map_value[,_long]()' in 'pcpu_copy_value()'.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libsodium23 < 1.0.18-150000.4.14.1 (version in image is 1.0.18-150000.4.11.1).

CVE-2023-54016 Severity: Moderate CVSS3 score: 4.3

Description: In the Linux kernel, the following vulnerability has been resolved:wifi: ath12k: Fix memory leak in rx_desc and tx_descCurrently when ath12k_dp_cc_desc_init() is called we allocatememory to rx_descs and tx_descs. In ath12k_dp_cc_cleanup(), duringdescriptor cleanup rx_descs and tx_descs memory is not freed.This is cause of memory leak. These allocated memory should befreed in ath12k_dp_cc_cleanup.In ath12k_dp_cc_desc_init(), we can save base address of rx_descsand tx_descs. In ath12k_dp_cc_cleanup(), we can free rx_descs andtx_descs memory using their base address.Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311 < 3.11.14-150600.3.41.2 (version in image is 3.11.14-150600.3.38.1).

CVE-2025-32728 Severity: Moderate CVSS3 score: 4.3

Description: In sshd in OpenSSH before 10.0, the DisableForwarding directive does not adhere to the documentation stating that it disables X11 and agent forwarding.

Packages affected:

sle-module-desktop-applications-release == 15.7 (version in image is 15.7-150700.28.1).
openssh > 0-0 (version in image is 9.6p1-150600.6.34.1).

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-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
python3-urllib3 > 0-0 (version in image is 1.25.10-150300.4.18.1).

CVE-2023-53759 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:HID: hidraw: fix data race on device refcountThe hidraw_open() function increments the hidraw device referencecounter. The counter has no dedicated synchronization mechanism,resulting in a potential data race when concurrently opening a device.The race is a regression introduced by commit 8590222e4b02 ("HID:hidraw: Replace hidraw device table mutex with a rwsem"). Whileminors_rwsem is intended to protect the hidraw_table itself, by insteadacquiring the lock for writing, the reference counter is also protected.This is symmetrical to hidraw_release().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54080 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:btrfs: zoned: skip splitting and logical rewriting on pre-alloc writeWhen doing a relocation, there is a chance that at the time ofbtrfs_reloc_clone_csums(), there is no checksum for the correspondingregion.In this case, btrfs_finish_ordered_zoned()'s sum points to an invalid itemand so ordered_extent's logical is set to some invalid value. Then,btrfs_lookup_block_group() in btrfs_zone_finish_endio() failed to find ablock group and will hit an assert or a null pointer dereference asfollowing.This can be reprodcued by running btrfs/028 several times (e.g, 4 to 16times) with a null_blk setup. The device's zone size and capacity is set to32 MB and the storage size is set to 5 GB on my setup. KASAN: null-ptr-deref in range [0x0000000000000088-0x000000000000008f] CPU: 6 PID: 3105720 Comm: kworker/u16:13 Tainted: G W 6.5.0-rc6-kts+ #1 Hardware name: Supermicro Super Server/X10SRL-F, BIOS 2.0 12/17/2015 Workqueue: btrfs-endio-write btrfs_work_helper [btrfs] RIP: 0010:btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] Code: 41 54 49 89 fc 55 48 89 f5 53 e8 57 7d fc ff 48 8d b8 88 00 00 00 48 89 c3 48 b8 00 00 00 00 00 > 3c 02 00 0f 85 02 01 00 00 f6 83 88 00 00 00 01 0f 84 a8 00 00 RSP: 0018:ffff88833cf87b08 EFLAGS: 00010206 RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000011 RSI: 0000000000000004 RDI: 0000000000000088 RBP: 0000000000000002 R08: 0000000000000001 R09: ffffed102877b827 R10: ffff888143bdc13b R11: ffff888125b1cbc0 R12: ffff888143bdc000 R13: 0000000000007000 R14: ffff888125b1cba8 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff88881e500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f3ed85223d5 CR3: 00000001519b4005 CR4: 00000000001706e0 Call Trace: ? die_addr+0x3c/0xa0 ? exc_general_protection+0x148/0x220 ? asm_exc_general_protection+0x22/0x30 ? btrfs_zone_finish_endio.part.0+0x34/0x160 [btrfs] ? btrfs_zone_finish_endio.part.0+0x19/0x160 [btrfs] btrfs_finish_one_ordered+0x7b8/0x1de0 [btrfs] ? rcu_is_watching+0x11/0xb0 ? lock_release+0x47a/0x620 ? btrfs_finish_ordered_zoned+0x59b/0x800 [btrfs] ? __pfx_btrfs_finish_one_ordered+0x10/0x10 [btrfs] ? btrfs_finish_ordered_zoned+0x358/0x800 [btrfs] ? __smp_call_single_queue+0x124/0x350 ? rcu_is_watching+0x11/0xb0 btrfs_work_helper+0x19f/0xc60 [btrfs] ? __pfx_try_to_wake_up+0x10/0x10 ? _raw_spin_unlock_irq+0x24/0x50 ? rcu_is_watching+0x11/0xb0 process_one_work+0x8c1/0x1430 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? __pfx_do_raw_spin_lock+0x10/0x10 ? _raw_spin_lock_irq+0x52/0x60 worker_thread+0x100/0x12c0 ? __kthread_parkme+0xc1/0x1f0 ? __pfx_worker_thread+0x10/0x10 kthread+0x2ea/0x3c0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x30/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 On the zoned mode, writing to pre-allocated region means data relocationwrite. Such write always uses WRITE command so there is no need of splittingand rewriting logical address. Thus, we can just skip the function for thecase.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54225 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:net: ipa: only reset hashed tables when supportedLast year, the code that manages GSI channel transactions switchedfrom using spinlock-protected linked lists to using indexes into thering buffer used for a channel. Recently, Google reported seeingtransaction reference count underflows occasionally during shutdown.Doug Anderson found a way to reproduce the issue reliably, andbisected the issue to the commit that eliminated the linked listsand the lock. The root cause was ultimately determined to berelated to unused transactions being committed as part of the modemshutdown cleanup activity. Unused transactions are not normallyexpected (except in error cases).The modem uses some ranges of IPA-resident memory, and whenever itshuts down we zero those ranges. In ipa_filter_reset_table() atransaction is allocated to zero modem filter table entries. Ifhashing is not supported, hashed table memory should not be zeroed.But currently nothing prevents that, and the result is an unusedtransaction. Something similar occurs when we zero routing tableentries for the modem.By preventing any attempt to clear hashed tables when hashing is notsupported, the reference count underflow is avoided in this case.Note that there likely remains an issue with properly freeing unusedtransactions (if they occur due to errors). This patch addressesonly the underflows that Google originally reported.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54271 Severity: Moderate CVSS3 score: 4.1

Description: In the Linux kernel, the following vulnerability has been resolved:blk-cgroup: Fix NULL deref caused by blkg_policy_data being installed before initblk-iocost sometimes causes the following crash: BUG: kernel NULL pointer dereference, address: 00000000000000e0 ... RIP: 0010:_raw_spin_lock+0x17/0x30 Code: be 01 02 00 00 e8 79 38 39 ff 31 d2 89 d0 5d c3 0f 1f 00 0f 1f 44 00 00 55 48 89 e5 65 ff 05 48 d0 34 7e b9 01 00 00 00 31 c0 0f b1 0f 75 02 5d c3 89 c6 e8 ea 04 00 00 5d c3 0f 1f 84 00 00 RSP: 0018:ffffc900023b3d40 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 00000000000000e0 RCX: 0000000000000001 RDX: ffffc900023b3d20 RSI: ffffc900023b3cf0 RDI: 00000000000000e0 RBP: ffffc900023b3d40 R08: ffffc900023b3c10 R09: 0000000000000003 R10: 0000000000000064 R11: 000000000000000a R12: ffff888102337000 R13: fffffffffffffff2 R14: ffff88810af408c8 R15: ffff8881070c3600 FS: 00007faaaf364fc0(0000) GS:ffff88842fdc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000000e0 CR3: 00000001097b1000 CR4: 0000000000350ea0 Call Trace: ioc_weight_write+0x13d/0x410 cgroup_file_write+0x7a/0x130 kernfs_fop_write_iter+0xf5/0x170 vfs_write+0x298/0x370 ksys_write+0x5f/0xb0 __x64_sys_write+0x1b/0x20 do_syscall_64+0x3d/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0This happens because iocg->ioc is NULL. The field is initialized byioc_pd_init() and never cleared. The NULL deref is caused byblkcg_activate_policy() installing blkg_policy_data before initializing it.blkcg_activate_policy() was doing the following:1. Allocate pd's for all existing blkg's and install them in blkg->pd[].2. Initialize all pd's.3. Online all pd's.blkcg_activate_policy() only grabs the queue_lock and may release andre-acquire the lock as allocation may need to sleep. ioc_weight_write()grabs blkcg->lock and iterates all its blkg's. The two can race and ifioc_weight_write() runs during #1 or between #1 and #2, it can encounter apd which is not initialized yet, leading to crash.The crash can be reproduced with the following script: #!/bin/bash echo +io > /sys/fs/cgroup/cgroup.subtree_control systemd-run --unit touch-sda --scope dd if=/dev/sda of=/dev/null bs=1M count=1 iflag=direct echo 100 > /sys/fs/cgroup/system.slice/io.weight bash -c "echo '8:0 enable=1' > /sys/fs/cgroup/io.cost.qos" & sleep .2 echo 100 > /sys/fs/cgroup/system.slice/io.weightwith the following patch applied:> diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c> index fc49be622e05..38d671d5e10c 100644> --- a/block/blk-cgroup.c> +++ b/block/blk-cgroup.c> @@ -1553,6 +1553,12 @@ int blkcg_activate_policy(struct gendisk *disk, const struct blkcg_policy *pol)> pd->online = false;> }>> + if (system_state == SYSTEM_RUNNING) {> + spin_unlock_irq(&q->queue_lock);> + ssleep(1);> + spin_lock_irq(&q->queue_lock);> + }> +> /* all allocated, init in the same order */> if (pol->pd_init_fn)> list_for_each_entry_reverse(blkg, &q->blkg_list, q_node)I don't see a reason why all pd's should be allocated, initialized andonlined together. The only ordering requirement is that parent blkgs to beinitialized and onlined before children, which is guaranteed from thewalking order. Let's fix the bug by allocating, initializing and onlining pdfor each blkg and holding blkcg->lock over initialization and onlining. Thisensures that an installed blkg is always fully initialized and onlinedremoving the the race window.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

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-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311 < 3.11.14-150600.3.41.2 (version in image is 3.11.14-150600.3.38.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libexpat1 > 0-0 (version in image is 2.7.1-150700.3.6.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glib2-tools < 2.78.6-150600.4.28.1 (version in image is 2.78.6-150600.4.25.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).

CVE-2023-54017 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: fix possible memory leak in ibmebus_bus_init()If device_register() returns error in ibmebus_bus_init(), name of kobjectwhich is allocated in dev_set_name() called in device_add() is leaked.As comment of device_add() says, it should call put_device() to dropthe reference count that was set in device_initialize() when it fails,so the name can be freed in kobject_cleanup().

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54030 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:io_uring/net: don't overflow multishot recvDon't allow overflowing multishot recv CQEs, it might get out ofhand, hurt performance, and in the worst case scenario OOM the task.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54091 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:drm/client: Fix memory leak in drm_client_target_cloneddmt_mode is allocated and never freed in this function.It was found with the ast driver, but most drivers using generic fbdevsetup are probably affected.This fixes the following kmemleak report: backtrace: [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm] [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm] [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm] [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper] [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper] [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm] [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast] [<00000000987f19bb>] local_pci_probe+0xdc/0x180 [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0 [<0000000000b85301>] process_one_work+0x8b7/0x1540 [<000000003375b17c>] worker_thread+0x70a/0xed0 [<00000000b0d43cd9>] kthread+0x29f/0x340 [<000000008d770833>] ret_from_fork+0x1f/0x30unreferenced object 0xff11000333089a00 (size 128):

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54140 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix WARNING in mark_buffer_dirty due to discarded buffer reuseA syzbot stress test using a corrupted disk image reported thatmark_buffer_dirty() called from __nilfs_mark_inode_dirty() ornilfs_palloc_commit_alloc_entry() may output a kernel warning, and canpanic if the kernel is booted with panic_on_warn.This is because nilfs2 keeps buffer pointers in local structures for somemetadata and reuses them, but such buffers may be forcibly discarded bynilfs_clear_dirty_page() in some critical situations.This issue is reported to appear after commit 28a65b49eb53 ("nilfs2: donot write dirty data after degenerating to read-only"), but the issue haspotentially existed before.Fix this issue by checking the uptodate flag when attempting to reuse aninternally held buffer, and reloading the metadata instead of reusing thebuffer if the flag was lost.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54177 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:quota: fix warning in dqgrab()There's issue as follows when do fault injection:WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0Modules linked in:CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541RIP: 0010:dquot_disable+0x13b7/0x18c0RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: dquot_load_quota_sb+0xd53/0x1060 dquot_resume+0x172/0x230 ext4_reconfigure+0x1dc6/0x27b0 reconfigure_super+0x515/0xa90 __x64_sys_fsconfig+0xb19/0xd20 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcdAbove issue may happens as follows:ProcessA ProcessB ProcessCsys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_suspend -> suspend all type quota sys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_resume ret = dquot_load_quota_sb add_dquot_ref do_open -> open file O_RDWR vfs_open do_dentry_open get_write_access atomic_inc_unless_negative(&inode->i_writecount) ext4_file_open dquot_file_open dquot_initialize __dquot_initialize dqget atomic_inc(&dquot->dq_count); __dquot_initialize __dquot_initialize dqget if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) ext4_acquire_dquot -> Return error DQ_ACTIVE_B flag isn't set dquot_disable invalidate_dquots if (atomic_read(&dquot->dq_count)) dqgrab WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) -> Trigger warningIn the above scenario, 'dquot->dq_flags' has no DQ_ACTIVE_B is normal whendqgrab().To solve above issue just replace the dqgrab() use in invalidate_dquots() withatomic_inc(&dquot->dq_count).

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54221 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:clk: imx93: fix memory leak and missing unwind goto in imx93_clocks_probeIn function probe(), it returns directly without unregistered hwswhen error occurs.Fix this by adding 'goto unregister_hws;' on line 295 andline 310.Use devm_kzalloc() instead of kzalloc() to automaticallyfree the memory using devm_kfree() when error occurs.Replace of_iomap() with devm_of_iomap() to automaticallyhandle the unused ioremap region and delete 'iounmap(anatop_base);'in unregister_hws.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
iproute2 > 0-0 (version in image is 6.4-150600.7.9.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.1).

CVE-2025-12781 Severity: Low CVSS3 score: 3.3

Description: When passing data to the b64decode(), standard_b64decode(), and urlsafe_b64decode() functions in the "base64" module the characters "+/" will always be accepted, regardless of the value of "altchars" parameter, typically used to establish an "alternative base64 alphabet" such as the URL safe alphabet. This behavior matches what is recommended in earlier base64 RFCs, but newer RFCs now recommend either dropping characters outside the specified base64 alphabet or raising an error. The old behavior has the possibility of causing data integrity issues.This behavior can only be insecure if your application uses an alternate base64 alphabet (without "+/"). If your application does not use the "altchars" parameter or the urlsafe_b64decode() function, then your application does not use an alternative base64 alphabet.The attached patches DOES NOT make the base64-decode behavior raise an error, as this would be a change in behavior and break existing programs. Instead, the patch deprecates the behavior which will be replaced with the newly recommended behavior in a future version of Python. Users are recommended to mitigate by verifying user-controlled inputs match the base64 alphabet they are expecting or verify that their application would not be affected if the b64decode() functions accepted "+" or "/" outside of altchars.

Packages affected:

sle-module-development-tools-release == 15.7 (version in image is 15.7-150700.28.1).
python3 > 0-0 (version in image is 3.6.15-150300.10.103.1).

CVE-2025-28162 Severity: Low CVSS3 score: 3.3

Description: Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via the pngimage with AddressSanitizer (ASan), the program leaks memory in various locations, eventually leading to high memory usage and causing the program to become unresponsive

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libpng16-16 < 1.6.40-150600.3.9.1 (version in image is 1.6.40-150600.3.6.1).

CVE-2025-28164 Severity: Low CVSS3 score: 3.3

Description: Buffer Overflow vulnerability in libpng 1.6.43-1.6.46 allows a local attacker to cause a denial of service via png_create_read_struct() function.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libpng16-16 < 1.6.40-150600.3.9.1 (version in image is 1.6.40-150600.3.6.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40311 Severity: Low CVSS3 score: 3.3

Description: In the Linux kernel, the following vulnerability has been resolved:accel/habanalabs: support mapping cb with vmalloc-backed coherent memoryWhen IOMMU is enabled, dma_alloc_coherent() with GFP_USER may returnaddresses from the vmalloc range. If such an address is mapped withoutVM_MIXEDMAP, vm_insert_page() will trigger a BUG_ON due to theVM_PFNMAP restriction.Fix this by checking for vmalloc addresses and setting VM_MIXEDMAPin the VMA before mapping. This ensures safe mapping and avoids kernelcrashes. The memory is still driver-allocated and cannot be accesseddirectly by userspace.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
gettext-runtime > 0-0 (version in image is 0.21.1-150600.3.3.2).

CVE-2026-1485 Severity: Low CVSS3 score: 3.3

Description: A flaw was found in Glib's content type parsing logic. This buffer underflow vulnerability occurs because the length of a header line is stored in a signed integer, which can lead to integer wraparound for very large inputs. This results in pointer underflow and out-of-bounds memory access. Exploitation requires a local user to install or process a specially crafted treemagic file, which can lead to local denial of service or application instability.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
glib2-tools < 2.78.6-150600.4.35.1 (version in image is 2.78.6-150600.4.25.1).

CVE-2026-1757 Severity: Low CVSS3 score: 3.3

Description: A flaw was identified in the interactive shell of the xmllint utility, part of the libxml2 project, where memory allocated for user input is not properly released under certain conditions. When a user submits input consisting only of whitespace, the program skips command execution but fails to free the allocated buffer. Repeating this action causes memory to continuously accumulate. Over time, this can exhaust system memory and terminate the xmllint process, creating a denial-of-service condition on the local system.

Packages affected:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libxml2-2 > 0-0 (version in image is 2.12.10-150700.4.6.1).

CVE-2026-1703 Severity: Low CVSS3 score: 3.1

Description: When pip is installing and extracting a maliciously crafted wheel archive, files may be extracted outside the installation directory. The path traversal is limited to prefixes of the installation directory, thus isn't able to inject or overwrite executable files in typical situations.

Packages affected:

sle-module-python3-release == 15.7 (version in image is 15.7-150700.28.1).
python311-pip > 0-0 (version in image is 22.3.1-150400.17.16.4).

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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
libruby2_5-2_5 > 0-0 (version in image is 2.5.9-150700.24.3.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54322 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:arm64: set __exception_irq_entry with __irq_entry as a defaultfilter_irq_stacks() is supposed to cut entries which are related irq entriesfrom its call stack.And in_irqentry_text() which is called by filter_irq_stacks()uses __irqentry_text_start/end symbol to find irq entries in callstack.But it doesn't work correctly as without "CONFIG_FUNCTION_GRAPH_TRACER",arm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irqbetween __irqentry_text_start and __irqentry_text_end as we discussed in below link.https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#tThis problem can makes unintentional deep call stack entries especiallyin KASAN enabled situation as below.[ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity[ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c[ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--)[ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c[ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c[ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0[ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000[ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd[ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040[ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000[ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20[ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8[ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800[ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8[ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c[ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022[ 2479.386231]I[0:launcher-loader: 1719] Call trace:[ 2479.386248]I[0:launcher-loader: 1719] __stack_depot_save+0x464/0x46c[ 2479.386273]I[0:launcher-loader: 1719] kasan_save_stack+0x58/0x70[ 2479.386303]I[0:launcher-loader: 1719] save_stack_info+0x34/0x138[ 2479.386331]I[0:launcher-loader: 1719] kasan_save_free_info+0x18/0x24[ 2479.386358]I[0:launcher-loader: 1719] ____kasan_slab_free+0x16c/0x170[ 2479.386385]I[0:launcher-loader: 1719] __kasan_slab_free+0x10/0x20[ 2479.386410]I[0:launcher-loader: 1719] kmem_cache_free+0x238/0x53c[ 2479.386435]I[0:launcher-loader: 1719] mempool_free_slab+0x1c/0x28[ 2479.386460]I[0:launcher-loader: 1719] mempool_free+0x7c/0x1a0[ 2479.386484]I[0:launcher-loader: 1719] bvec_free+0x34/0x80[ 2479.386514]I[0:launcher-loader: 1719] bio_free+0x60/0x98[ 2479.386540]I[0:launcher-loader: 1719] bio_put+0x50/0x21c[ 2479.386567]I[0:launcher-loader: 1719] f2fs_write_end_io+0x4ac/0x4d0[ 2479.386594]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300[ 2479.386622]I[0:launcher-loader: 1719] __dm_io_complete+0x324/0x37c[ 2479.386650]I[0:launcher-loader: 1719] dm_io_dec_pending+0x60/0xa4[ 2479.386676]I[0:launcher-loader: 1719] clone_endio+0xf8/0x2f0[ 2479.386700]I[0:launcher-loader: 1719] bio_endio+0x2dc/0x300[ 2479.386727]I[0:launcher-loader: 1719] blk_update_request+0x258/0x63c[ 2479.386754]I[0:launcher-loader: 1719] scsi_end_request+0x50/0x304[ 2479.386782]I[0:launcher-loader: 1719] scsi_io_completion+0x88/0x160[ 2479.386808]I[0:launcher-loader: 1719] scsi_finish_command+0x17c/0x194[ 2479.386833]I---truncated---

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-40359 Severity: Low CVSS3 score: 2.5

Description: In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Fix KASAN global-out-of-bounds warningWhen running "perf mem record" command on CWF, the below KASANglobal-out-of-bounds warning is seen. ================================================================== BUG: KASAN: global-out-of-bounds in cmt_latency_data+0x176/0x1b0 Read of size 4 at addr ffffffffb721d000 by task dtlb/9850 Call Trace: kasan_report+0xb8/0xf0 cmt_latency_data+0x176/0x1b0 setup_arch_pebs_sample_data+0xf49/0x2560 intel_pmu_drain_arch_pebs+0x577/0xb00 handle_pmi_common+0x6c4/0xc80The issue is caused by below code in __grt_latency_data(). The codetries to access x86_hybrid_pmu structure which doesn't exist onnon-hybrid platform like CWF. WARN_ON_ONCE(hybrid_pmu(event->pmu)->pmu_type == hybrid_big)So add is_hybrid() check before calling this WARN_ON_ONCE to fix theglobal-out-of-bounds access issue.

Packages affected:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2025-66861 Severity: Low 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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-basesystem-release == 15.7 (version in image is 15.7-150700.28.1).
binutils > 0-0 (version in image is 2.45-150100.7.57.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE-2023-54267 Severity: Moderate CVSS3 score: 0.0

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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.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:

sle-module-public-cloud-release == 15.7 (version in image is 15.7-150700.28.1).
kernel-azure < 6.4.0-150700.20.24.1 (version in image is 6.4.0-150700.20.21.1).

CVE scan

Summary of CVEs affecting the image: